►
From YouTube: OMR Architecture 20210304
Description
Agenda:
* Refactoring and cleanup of Linkage properties (#5836) [ @janvrany ]
* Preferred Jenkins trigger for CI jobs [ @fjeremic ]
A
C
D
D
B
E
D
Also
there
is
a.
There-
is
a
quite
a
bit
of
code,
duplication
in
within
the
backend
itself,
because,
as
far
as
I
could
see
in
every
constructor
of
every
linkage,
you
set
up
the
you
set
up
the
linkage
properties.
So
you
fill
the
values.
You
know
the
register,
flags
and
everything
and
all
the
all
the
data
structure
you
fill
it
in
and
then
continue.
B
E
D
For
virtuals
goals-
and
things
like
this-
which
I
mean
they
don't
hurt,
but
on
the
other
hand,
that's
you
know
where
the
j9,
the
consumer
project
leaks
into
the
into
the
omr,
which
is
something
that
I
guess
would
be
nice
to
avoid,
and
the
other
thing
is
that
you
know
the
meaning
of
the
of
the
properties
or
the
members
of
the
proper
of
the
linkage.
Properties
are
well
not
very
well
documented,
and
sometimes
sometimes
I
struggled
what
they
really
mean,
especially
on
power.
D
After
working
with
the
code
for
a
while,
I
observe
few
things.
First
of
all
that
that
all
the
linkage
properties,
I've
seen
use
a
quite
a
lot
of
derived
values.
So
there
are
some,
you
know
primary
values
like
a
register
flags,
and
then
you
know
in
that
you
have
this.
You
know
this
is
a
integer
argument
or
an
integer
return
register
like
you
define
the
roles
of
the
register
in
in
the
linkage
yeah.
D
D
B
B
D
Therefore
they
are
created
once
and
not
each
time
you,
you
instantiate
the
linkage
which
might
save
a
little
bit
of
memory
and
maybe
a
tiny
bit
of
time,
but
you
know
the
overall
effect
on
performance.
I
don't
want
to
presume
that
you
know
it
would
make
much
difference,
probably
not,
but
you
can
do
it
and
once
you
have
this.
E
D
C
D
D
D
D
So
here
here
I
create
yet
another
subclass,
and
I
do
that
only
so
I
can.
I
can
have
a
constructor
in
there
and
if
I
go
into
the
constructor,
let
me
see
if
I
can
do
this.
Yes,
so
you
see
that
pretty
much
all
I
do
here
is
just
I
fill
in.
You
know
these
properties
and
I
fill
in
the
register
flags-
and
this
is
this-
is
pretty
straightforward.
If.
D
D
D
D
So
if
I
want
to
make
any
change
in
the
system
linkage
for
whatever
reason,
I
just
change
the
flags
here
and
and
that's
it
if
I'm
about
to,
if
I'm
about
to
implement
a
j9,
private
linkage
or
any
other
private
linkage
in
any
other
consumer
project,
I
use
the
same
pattern.
I
just
fill
in
the
register
flags
and
after
that
I
call
initialize
and
it
fills
fills
the
rest.
D
D
F
F
D
D
F
A
A
So
I
don't
even
remember
what
some
of
the
reasoning
was
behind
creating
a
separate
system,
linkage,
properties
class,
I
know-
and
there
are
places
in
the
code
where
we
actually
create
a.
We
actually
do,
pull
it
out
into
a
variable,
and
then
we
ask
that
variable
questions
about
the
properties,
but
I
don't
know
why
we
couldn't
just
do
that
on
the
linkage.
F
D
D
D
D
F
D
B
B
D
When
when
we
tried
to
use
the
common
stuff
and
then
extend
and
see
how
how
it's
done
in
power
and
in
power,
it's
actually
not
that
nice,
I
didn't-
I
didn't-
I
didn't
have
enough
time
to
to
think
how
to
make
it
even
nicer.
But
still
you
saved
quite
a
bit
of
code
on
power
right.
So
here
we
go
to
the
power
linkage
and
we
have
we
have
all
this
and
we
have
all
these.
D
D
D
So
this
is
an
this
is
kind
of
a
proof
that
you
can
extend
the
you
can
extend
and
accommodate
for
for
the
specifics,
and
also
this.
This
gives
us
mechanism
how
to
get
how
to
get
the
j9
specific
properties
out
of
this
one
big
property,
because
because
then
the
j9
linkage
j9
private
linkage.
We
just
add
these
into
it,
just
like
like
it's
done
here
right,
but
it
would
be
in
the
j9
code,
not
in
the
omr
code.
D
B
D
D
So
this
is
pretty
much
a
blind
refactoring,
but
the
problem
problem
here
why
it
cannot
be
static.
Is
that
essentially,
essentially,
what
we've
done
in
in
risk?
Five
is
that
that
we
move
this
into
the
constructor
of
the
linkage
properties
all
this
code,
but
we
cannot
do
it
easily
here,
because
here
is
all
conditional
and
in
the
static
constructor
or
in
the
constructor,
that
is
called
for
a
static
variable.
D
D
D
One
way
one
way
would
be
would
be
having
having
like
a
three
different
classes
for
system
linkage:
properties
like
a
32-bit
aix,
32-bit,
linux,
64-bit,
linux,
64-bit,
aix,
and
also
now.
I
learned
thanks
to
boris,
that
there
is
yet
another
api
of
motorola
which,
which
is
used
on
some
32-bit
power.
Pcs
of
our
interest,
which
I
don't
think
is
accommodated
here.
D
D
B
Okay,
I
have
big
doubts
about
that
whole
thing.
You
know
on
every
line
when
you
say
well,
we
cannot
really
look
that
we
cannot
really
compute
that
statically
like
that
is
little
indian
or
where
was
the
line
that
that
you
just
showed
us.
I
have
a
general
discontent
about
even
having
that,
because
that's
like
pretending
that
we
have
cross-jitting
or
well
cross
compilation
that
never
worked
and
and
when
you
try
looking
at
it.
B
For
example,
if
I
try
to
cross
jit
from,
I
don't
know
little
indian
power
to
big
indian
power,
the
whole
structure
of
the
code
has
got
much
bigger
problems
than
that
than
any
of
this.
So
I
don't
see
why
we
even
have
that
that
that
should
all
be
define
the
compiler
constants
at
compilation,
time
that
just
are
defined
early
enough
that
this
problem
about.
Well,
we
cannot.
B
A
Yes,
of
course,
just
just
so,
I
understand
what
you
were
proposing.
Your
your
thinking
is
that
the
entire
property
should
simply
just
be
a
constant,
or
they
should
all
just
be
constants,
and
there
shouldn't
be
a
need
to
update
them
during
initialization
at
all.
There
should
be
one
representation
for
each
kind
of
linkage
that
we
want
to
to
to
have.
B
No,
that's
not
what
I
said,
jan
on
your
screen,
can
you
go
to
that
if
indirect,
indirect,
indirect
is
yeah
yeah,
something
like
that?
Yes,
yes,
is
big
endian.
What
I
am
saying
is
that
dynamic
redirection
from
compilation
to
target
to
cpu
to
is
big
endian
makes
no
sense.
I
mean
you
could,
but
you
always
know
whether
it
is,
is
big
endian
or
not.
B
Now
I'm
not
advocating
against
what
you
just
said
right
that
these
things
should
be
just
static
constants,
but
you
know
that
that
that's
it
that's
a
different
thing.
Jan's
problem
was
that
we
cannot
conditionally
or
with
a
small
wind
palms
alignment
right
lying
right.
Dependent
on
is
big
indian,
because
in
a
static
constructor
or
what
you
call
it,
you
don't
have
access
to
is
big
indian,
but
that
is
simply
because
right
now,
this
whole
construction
about
is
big.
Indian,
being
dynamic.
A
B
B
B
A
Okay,
so
some
of
this
code
is
is
historical,
so
where,
where
this
code,
where
some
of
those
kinds
of
changes
were
introduced,
was
back
at
a
time
when
cross
compilation
was
certainly
a
possibility,
we
could
run.
We
could
run
on
x86
hardware
and
generate
code
for
a
power
pc
machine,
so
that
was
certainly
a
possibility.
A
The
the
a
lot
of
that
functionality
sort
of
eroded
over
time
and
we're
kind
of
at
a
state
where
it
likely
doesn't
work.
That
is
not
a
path
that
that
actually
works,
and,
in
fact,
when
we
re-architected
the
code
to
open
source,
we
I
think
we
deliberately
had
to
make
a
choice
about
whether
or
not
we
were
going
to
support
cross-compilation,
and
the
answer
was
no
just
to
make
the
the
open
sourcing
easier.
However,
I
think
looking
forward
cross-compilation
is
not
going
to
be
off
the
table.
B
Okay,
so
now
I
am
really
happy
because
I
mean
it's
it's
diverging
very
far
from
today's
topic,
but
at
least
we've
got.
You
know
some
concrete
talking
about
well,
what
exactly
the
goals
of
omr
are
here,
and
I'm
very
happy
to
hear
that.
Yes,
this
something
that
would
be
important
for
our
use
case
at
that
at
labor.
B
A
A
Those
are
all
left
over
from
the
days
where
we
did
where
we
did
cross
compilation.
So
if
we
do
something
like
that
in
the
future,
we're
going
to
have
to,
I
think,
put
her
in
a
fairly
we're
going
to
have
to
essentially
overhaul
the
entire
compiler
here
to
understand
how
like
what
what's
correct
and
what
isn't
correct
and
and
to
make
it
so
so
that
issue
that
I,
that
I
mentioned
that
I
can
dig
up
for
you
does
touch
on
some
of
that,
but
it
it's.
I
mean
you're
right.
A
A
A
Right
so
I
was
thinking
I
was
trying
to
think
in
my
mind
what
some
of
the
motivations
could
have
been
for
separating
the
linkage
properties
into
a
separate
class
originally,
and
I
think
that
one
of
the
original
motivations
from
that
would
have
been
that
when
you're
looking
at
two
calling
conventions
that
are
very
similar
to
each
other
and
I'll
go
back
to
that
time.
What
was
around
at
that
time?
You'd.
A
Look
at
32-bit
windows
versus
32-bit,
linux
they're
very
similar,
but
they
have
some
subtle
differences
in
terms
of
like
how
you
handle
the
value
being
returned
from
the
stack
and
whose
responsibility
is
it
to
clean
up
the
stack
on
on
a
call
they're,
largely
the
same
except
a
couple
of
properties
are
different.
I
think
the
goal
there
was
to
produce
a
sort
of
a
a
common
and
I'll
just
pick
system.
Linkage,
let's
say
pick
a
a
system,
linkage
that
had
the
same
sort
of
logic,
identical
logic
for
windows
and
linux.
A
But
the
difference
was
the
properties
class.
You
could
define
a
linux
specific
property
class
where
you
could
define
a
windows,
specific
property
class
and,
depending
upon
what
the
settings
were
in
those
different
properties,
the
the
the
common
linkage
implementation
would
do
different
things
at
the
different
points
right.
So,
oh,
I
need
to
clean
up
the
stack
here
or
I
need
to
push
this
value
now
or
that
kind
of
thing.
A
A
So
I
think,
if
we're
going
to
try
to
understand
what
the
right
way
to
architect
to
re-architect
linkage
and
linkage
properties,
I
think
we
need
to
think
of
what
role
do
we
want
to
have?
What
are
we
trying
to
accomplish
with
having
a
separate
linkage
properties,
because
if
we
go
the
approach
that
perhaps
philip
was
advocating
that
suggests
that
that
properties
aren't
shared
in
that
way,
they're
shared
more
through
the
sharing
of
or
the
the
the
subclassing
of
of
the
linkage
hierarchy.
A
D
Static
well,
to
be
honest,
I
I
still
kind
of
prefer
to
have
a
linkage
link
is
perfectly
simple
too.
One
reason
is
yeah,
you
can
you
can
share
them
and
you
know
that's.
You
know
the
difference.
The
telling
difference,
what
is
the
linkage
properties,
and
what
is
the
linkage
is
the
linkage
properties
are
static.
Immutable
data,
pretty
much
same
for
for
all
also
another
reason
for
me
to
to
make
them
separate
is
that
the
linkage
class
is
usually
a
monster
in
itself
and
putting
more
legs
onto
it
would
make
it.
A
With
the
way
that
you've
done
things
with
the
linkage
class
on
risk
five,
I
guess
I'm
I'm
trying
to
understand.
Are
there
unique
requirements
that
you
have
on
risk?
Five
that
you
were
trying
to
solve,
with
the
way
that
you
did
it
so,
for
example,
is
the
savings
that
is,
is
whatever
start
startup
time
savings
that
you're
getting
is.
That
is
that?
Is
it
really
that
critical
on
risk?
Five?
I'm
not
saying
that!
That's
a
bad
thing,
I'm
just
trying
to
understand
no.
A
D
D
D
Then
I
believe
you
know
in
10
minutes
I
can
just
delete
150
lines
of
code
from
from
air
64
back
end
and
in
turn
in
you
know,
another
50
or
60
lines
of
code
in
the
j9
in
the
j9
j9
r64
private
linkage,
because
then
I
will
only
set
the
register
flex
and
a
few
other
bits
and
then
go
initialize
to
to
do
the
rest.
So
that
was
the
that
was
the
primary
primary
motivation.
I
didn't
want
to
contribute
and
add
another
copy-pasted
code.
A
Yeah
and
and
first
of
all,
I'll
I'll.
Thank
you
for
that.
It's
a
very
I'm
glad,
I'm
very
happy
to
see
that
you're
you're
you're
you're,
considering
that
kind
of
thing
it's
it's
certainly
a
problem
that
and
you've
obviously
you're
seeing
it
here
with
the
with
the
way
the
linkage
class
has
evolved
over
the
last
20
years
and
with
the
with
the
different
directions
that
different,
architectures
or
even
different
operating
systems
have
have
chosen
to
to
to
take
it.
A
A
I
think
the
we
do
need
to
give
some
thought
as
a
as
a
group
on
what
it
is
that
we're
trying
to
like
how
how
these
I
think
deciding
on
what
it
is
that
we're
trying
to
how
we
want
these
linkage
classes
to
behave
will
determine
what
some
of
the
architectural
choices
are
that
we
make
like
do.
We
need
a
separate
class
for
the
properties
should
they
be
do
we
need
to
like
how
do
we
encourage
more
sharing
across
different
linkages?
A
Things
like
that
yeah
and
what
the
best
way
of
doing
that
is.
I
I
mean
I,
I
think
that
you're
not
going
to
get
many
arguments
and
somebody
please
step
up
and
argue
that
startup
time
is
important.
So
we
should
try
to
minimize
that
as
much
as
possible,
sharing
as
much
of
it
as
possible
would
be
would
be
ideal
as
well.
A
I'm
not
so
convinced
of
that
one
though,
but
but
but
still
it's
it's
something
maybe
to
put
on
the
table.
Actually,
I
I
may
take
that
one
back.
There
are
some
very
common
operations
that
occur
in
linkages
that
that
that
definitely
would
be
shared
so,
for
example,
for
a
particular
language
environment.
How
do
you
map
values
onto
the
stack
right
like
there
might
be
a
lot
of
similar
code
there?
That
would
be
shared
across
the
different
architectures?
D
That
can
be
you
know,
shared
by
by
just
you
know,
splitting
into
multiple
pieces
like
having
you
know
this,
this
sort
of
template
methods
and
then
smaller,
smaller
stuff.
So
so
I
think
there
is
a
great
potential-
and
I
guess
in
the
end-
and
that's
that's
a
rough
estimate,
and
maybe
maybe
too
optimistic,
but
I
guess
we
can
save
up
to
30
percent
of
the
code
in
each
back
end
by
by
doing
this.
A
A
There
are
some
very
seemingly
minor
reasons
why
a
lot
of
that
is
is
somewhat
challenging
to
do
at
the
moment,
and
I
know
that
myself
and
I
know
philip
has
been
chipping
away
at
at
little
bits
of
it
as
well,
trying
to
make
it
easier
for
code
to
be
shared
across
the
the
different
code
gen.
So
just
as
an
example,
you
know
if,
if,
if
the
like,
what
the
register
enum
is
in
some
cases
would
prevent,
because
every
architecture
used
to
have
their
own
enum.
A
A
That
code
is,
I
think,
there's
even
an
issue
open
for
commenting
this
up
that
code.
I
think
is
pretty
much
identical
across
every
architecture
except
arm
the
32-bit
iron.
It's
the
only
one
out,
so
there's
no
reason
why
that
code,
for
example,
couldn't
just
be
shared,
so
we
need
to
go
through
and
and
and
map.
Some
of
these
linkage
functions
into
common
ones
that
can
be
shared
across
the
different
architectures.
A
A
I
I
wouldn't
say
that
this
like
what
you've
done
here
is
is
not
I.
I
wouldn't
say
that
this
is
code
that
we
wouldn't
want
to
accept.
I
mean
it's
it.
It's
just
done
a
different
way,
just
like
every
other
architecture
has
done
it,
but
you
know
certainly
some
of
the
ideas
you
have
on
on
sharing,
I
think,
could
be
perhaps
to
be
taken
into
account
too.
D
Well,
from
my
point
of
view
there,
there
are
two
two
things
right
as
I
was
working
on.
The
first
few
comments
just
did
everything
I
think
yeah
up
to
here
they
did
everything
locally
in
a
in
a
risk.
Five
code
gen-
and
I
am
kind
of
happy
with
that
code
and
I
started.
I
started
hacking
all
these,
because
I
wanted
to
do
something
about
it
before
I
start
up
streaming.
The
private
linkage
to
j9
right
the
way.
E
D
It
right
now
it's
really
hacky
and
I
don't
want
get
this
hacks
and
horrible
code
to
be
upstream,
so
I
started
to
polishing
it
here.
So
the
first
question
is:
if,
if
this
is
okay
enough
to
accept
it
inside
the
risk,
five
coaching
and
that's
something
that
then
something
I
can
probably
you
know
polish
and
squash
the
comments
and
just
upstream
what
to
do
with
the
rest.
D
A
First
of
all,
any
rear,
any
re-architecting
we
do
with
the
linkage
class,
I
think,
is
going
to
affect
every
architecture,
and
it
would
be
ideal
if
and
actually
that's
how
it
should
be-
that
every
architecture
gets
changed.
The
same
way
like
we
should
all
be
doing
the
same
kind
of
thing
so
right
now
that
means
a
different
amount
of
rework
that
has
to
happen
on
x.
To
make
that
happen,
a
different
amount
of
rework
on
power
on
arc64
and
then
even
on
whatever
you
do
in
risk,
five
is
going
to
have
to
get
re-architected.
A
A
A
D
D
A
Can
someone
that's
familiar
with
the
code?
Remind
me,
is
linkage
pro
and
perhaps
yeah
you're,
the
you're
the
person
to
do
it
is
linkage
properties
right
now
in
the
base,
omr
linkage
class,
or
does
it
only
exist
in
the
that
first
architecture,
layer
like
it
would
be
in
the
in
the
power,
co,
power
linkage
or
x86
linkage
or
risk
5
linkage
is
that
where
the
first
occurrence
of
the
linkage
properties
is.
A
The
reason
I'm
saying
that
is
because,
if
you,
if,
if
risk
five
decided
that
the
way
that
you
wanted
to
implement
this
was
to
make
the
linkage
property
static,
that
would
be
a
decision
that
you
make
in
the
risk
5
specialization
of
the
linkage
hierarchy,
so
you're
certainly
free
to
do
it.
That
way,
if
that's
the
way
that
you
wanted
to
do
it.
A
I'm
just
looking
at
at
least
on
x86.
They
lit
yeah
there.
There
is
no
properties
in
the
in
the
base
class,
so
making
that
a
static
is
the
way
that
I
mean
that
that
could
be
the
way
that
you
do
that
now,
but
as
as
philip
was
saying,
some
of
these
decisions
may
get
revisited
in
the
future
as
we
do
a
proper
and
a
more
consistent
re-architecting
of
the
linkage
code
across
all
architectures.
A
D
A
A
A
Re-Architect,
the
linkage
essentially
and
over
the
years
I've
been
adding
various
issues
to
it
or
I've
been
tagging.
Various
issues
there
just
to
track
some
of
the
evolution
of
of
of
the
code
as
we
as
we
go
on
so
feel
free
to
look
at
that
add
any
thoughts
you
have
to
to
that
body
of
of
issues
as
we
go
forward
at
some
point.
A
A
A
Okay,
thank
you.
I
have
a
q.
I
have
a
question
for
boris.
If
you,
if
you
don't
mind
you,
you
mentioned
that
cross-compilation
or
having
the
ability
to
do,
cross-compilation
is
aligned
with
some
of
the
interests
that
you
have.
Are
you
able
to
elaborate
on?
Are
you
really
able
to
elaborate
on
that
at
all
like
what?
How
how
do
you
foresee
using
cross
compilation
in
your
in
your
environment,.
B
You
need
to
you
need
to
actually
cross
compile,
not
just
cross
build
right,
because
if
you
simply
cross
build,
then
you
have
an
aot,
compiler
or
jit
compiler
or
you
know
whatever
right,
you
have
a
compiler
that
bootstraps
from
power
pc,
but
you
don't
have
a
small
talk
image
that
will
call
that
and
feed
it.
The
base
class
hierarchy
that
you're
trying
to
aot
in
the
first.
B
But
there
is
like
basic
things
like
when
you,
when
you
binary
and
code
and
instruction
you
just
left
to
right
or
the
different
fields,
and
there
is
no
attempt
to
bite
swap
when
you're
doing
cross
indian
and
I
was
searching
the
code
and
trying
to
grab
on
different.
You
know
likely,
and
I
wasn't
finding
anything
like
well.
How
do
you
you
know?
B
How
do
you
bite
swap
when
you
do
when
you
do
a
a
cross
compiler
and
I
was-
and
I
was
looking
at
the
code
visually
as
well,
and
I
was
like
okay
well,
there
is
not
even
an
attempt
to
to
do
anything
like
that,
and
then
you
know
when
there
is
a
whole
bunch
of
these.
You
know
usual
suspects
right
what
you
what
you
need
to
be
doing
when
you
were
dynamically
cross
compiling
and
they
weren't
there,
and
I
was
like
okay
well.
This
was
couple
years
ago.
So,
okay,
this
is
really
too
bad.
B
So
we
cannot
use
this
to
cross
aot.
Our
small
talk,
so
we're
gonna
go.
You
know
some
other
way
and
and
and
we
used
some
resources
to
to
do
this-
bootstrapping
aot
completely,
not
using
omr
and-
and
you
know
that
was
based
on
this
impression-
that
okay,
well,
we
just
don't
have
cross
compilation
because
well
fundamentally,
yeah
there
are
some.
There
are
some
bits
that
that
try
to
do
it,
but
then
there
are
fundamental
bits
that
are
missing
and.
A
They
would
obviously
still
be
there
in
a
in
a
in
in
a
in
a
cross-compilation
world,
but
but
yeah
more
work
for
sure
needs
to
get
done
there
right
all
right.
Well,
thanks
thanks
for
sharing
that
that
use
case
with
us,
it's
good
to
know
that
there
are,
you
know,
other
than,
let's
say
a
a
jit
server
kind
of
environment.
It's
good
to
know
that
there's
there
are
other
use
cases
of
this
as
well.
B
B
A
F
Take
us
through
this
sure,
we'll
make
this
pretty
quick.
So
eclipse
the
eclipse
organization
is
the
their
it.
Folks
are
the
ones
who
manage
the
genie,
omr
github
account
and
it
seems
they
have
deleted
that
user
id
and
are
replacing
it
with.
I
think
eclipse,
omr
bot
or
something
like
that.
I
think
they're
in
the
transition
of
doing
that
for
all
the
projects.
F
So
I
guess
this
is
a
good
point
to
kind
of
come
back
to
the
community
and
ask
if
we
want
to
change
that
moving
forward
to
a
different
keyword,
or
do
we
still
stick
with
genie
omar
or
do
we
change
it
to
something
completely
different?
And
I
guess
adam
is
here
on
the
call
as
well.
I
don't
know
if
there's
anything
else,
you
want
to
add
adam.
E
E
So
it
the
trigger
causes
a
bit
of
confusion,
because
everybody
thinks
it's
linked
to
the
bot
account,
but
it's
really
not
so
we
can
either
leave
it
as
is
as
genie
omar
or
we
can
link
it
to
the
new
name
or
some
other
name
or
some
other
trigger
altogether,
which
doesn't
have
an
ad.
So
it's
really
up
to
you.