►
From YouTube: OMR Architecture Meeting 20220203
Description
Agenda:
* Eclipse OMR 2021 review and 2022 goals
A
Okay,
welcome
everyone
to
the
first
omr
architecture,
meeting
of
2022,
as
is
the
tradition
for
the
past
few
years.
We
will
take
the
the
first
meeting
of
the
year
to
have
a
look
back
at
what
we
were
able
to
accomplish
in
2021
and
then
spend
some
time
looking
at
some
of
the
goals
that
we
have
for
the
project
this
year.
A
As
is
always
the
case,
it's
it's
not
always
easy
to
come
up
with
what
the
goals
are
going
to
be.
They're,
certainly
aspirational,
but
things
do
come
up
during
the
year
that
will
that
will
cause
us
to
change
direction
or
whatever,
but
we'll
do
the
best
that
we
can
on
the
information
that
we
have
so
far.
A
Okay,
so
from
a
project
perspective,
there
were
a
few,
a
few
things
that
happened
here
so
first
off
we
still
have
a
very
healthy
rate
of
of
pull
requests
and
issues
being
being
created.
We
were
able
to
merge
434
pull
requests.
Last
year,
I
should
have
probably
provided
some
statistics
on
a
number
of
people
and
number
of
new
people
contributing
as
well.
I
don't
have
that
information,
though,
but
I
do
know
that
there
were
a
number
of
of
people
that
were
new
to
the
project
that
first
made
their
contribution.
A
Last
year
we
have
two
new
committers
to
the
project,
irwin
and
and
devin,
bringing
us
to
13
in
total.
So
that's
great
to
see
and
of
the
issues,
that
of
of
all
the
good
first
issues
that
we
have.
We
had
seven
of
them
taken
by
by
newer
people
and
and
moved
to
completion
and
got
their
their
code
contributed
so
good
for
the
project.
A
A
It's
been
on
the
plan
for
many
years.
We
had
our
first
discussion
on
this
back
in
early
2018,
and
it
wasn't
until
last
year
that
gidi
really
took
that
in
and
started
running
with
it,
and
the
idea
was
to
figure
out
an
acceptable
way
of
of
re-architecting
support
for
newer
vector,
op
codes
that
supported
different
shapes
and
different
element
types.
A
There's,
the
the
what
we
have
right
now
is
sort
of
based
on
128-bit
shape,
but,
as
we
certainly
know
from
various
architectures
out
there,
there
are
other
widths
that
that
the
need
to
that
we
need
to
care
about
completely
honest.
A
lot
of
this
is
being
driven
by
the
vector
api
in
java
and
some
of
the
the
the
work
that
needs
to
happen
for
that.
But
the
good
thing
for
that.
A
A
We
also
had
a
fairly
significant
reduction
in
compiler
warnings,
so
many
of
the
components
within
omr
already
build
with
with
warnings
as
errors
and
the
compilers
sort
of
stood
out.
There
were
a
number
of,
and
a
lot
of
that
really
came
into
the
eclipse
omar
project
from
before
the
from
from
when
it
was
sorry
from
before
it
was
open
source.
So
it
really
inherited
a
lot
of
the
warnings
in
that
that
did
not
get
cleaned
up
before
the
code
was
contributed.
A
So
there
was
a
fair
bit
of
effort
last
year
to
tackle
a
lot
of
the
the
warnings
that
were
being
produced
in
a
couple
of
the
back
ends
and
a
couple
of
the
builds
and
to
the
point
where
the
state
on
on
x86
and
on
z.
They
got
down
to
zero
errors
and
we
were
able
to
enable
warnings
of
theirs
on
their
on
those
components.
So
so
really
good
progress
there.
A
The
the
in
in
terms
of
back
end
work.
There
was
a
fair
bit
of
work
happening
on
art
64
last
year.
Again,
a
lot
of
that
was
being
driven
by
requirements
for
java,
but
but
again
the
the
omr
project
benefits
from
that
some
of
the
work
that
really
happened.
There
was
around
a
full
128-bit
cindy
support.
So
this
is
the
neon
work
array,
copy
implementation
and
many
many
performance
improvements
to
to
get
that
code,
generator,
ready
and
in
shape
for
for
delivery.
A
You
know
really
shining
a
light
on
some
of
the
darker
corners
of
of
some
parts
of
the
the
compiler
in
particular,
and
not
only
just
not
only
just
technology
concepts
but
even
processes
as
well
like
how
do
we
do
things
and
how
do
you?
How
do
you
interpret
a
log
file
that
sort
of
thing?
So
a
lot
of
good
work
happened
there,
and
I
certainly
expect
that
to
continue
going
forward
here.
A
There
was
some
more
work
being
done
to
converge
the
to
converge,
the
code
generators.
You
know
there.
There
certainly
is
a
lot
of
similarities
between
them.
You
know,
we've
discussed
this
many
times
in
the
past
and
there
are
lots
of
opportunities
for
convergence,
but
it's
a
big
effort.
It's
a
it
requires
a
lot
of
coordination
between
the
different
back
ends
and
many
many
files,
and
things
like
that
have
to
get
touched.
A
So
we
tend
to
do
things
in
in
little
spurts,
but
last
year
we
were
able
to
to
to
handle
a
few
things,
so
one
of
which
was-
and
we
talked
about
this
in
in
the
omar
architecture
meeting
here-
was
really
sort
of
normalizing
the
il
opcode
evaluator
nomenclature,
so
they
all
have
a
similar
name.
It's
easy
to
find
things
and
easier
to
debug
that
way,
so
so
that
work
that
work
happened.
A
There
were
other
aspects
to
the
to
other
things
that
were
changed
in
the
code:
generators
as
well
as
part
of
that
didn't
list
all
of
them
here,
but
but
suffice
it
to
say
that
you
know,
even
though
we're
still
a
long
way
from
some
of
the
convergence
goals
that
we
have.
You
know
some
progress
was
being
made
last
year.
A
But
one
of
the
reasons
it
hasn't
merged
is
because
he's
actively
working
on
jit
builder,
two
point
x,
which
which
will
likely
supersede
that
that
particular
pr.
So
I
think
this
year.
One
of
the
things
we
can
expect
to
see
is
a
bit
more
discussion
on
on
the
jit
builder
api
and
how
that's
going
to
evolve.
A
We're
also
still
looking
at,
we
also
were
motivated
to
look
at.
I
mean
sorry
well
motivated
by
doing
omr
releases.
We
started
looking
at
how
we
can
define
the
compiler
api.
The
compiler
is
obviously
the
the
component.
That
is,
is
it's
the
most
major
component
that
doesn't
have
a
an
api
that
we
can
standardize
on
and
that
we
can
we
conversion
across
different
releases.
A
So
we
wanted
to
make
some
progress
on
that,
and-
and
we
did-
albeit-
albeit
not
very
much,
but
you
know
there
were
some
ideas
thrown
around
last
year
on
how
to
make
some
some
progress
on
that.
So,
but
you
mean
the
the
longer
term
goal
for
for
omar
still
is
to
to
be
a
versioned,
is
to
produce
releases
and
have
versioned
apis
for
all
its
components
so
that
we
can
track
things
so.
A
In
some
of
the
other
components,
some
of
the
major
things
that
happened
earlier
last
year
we
talked
about
a
port
library,
initialization
api
for
the
compiler
and
jit
builder.
This
is
really
more
along
the
lines
of
of
hardening
the
dependency
between
the
compiler
and
and
and
the
port
library.
There's
a
lot
of
we've.
We've
talked
about
lots
of
that
in
the
past,
but
there
was
an
attempt
earlier
last
year
to
to
work
on
the
api
to
to
initialize
builder
with
the
compiler.
A
A
We
also
talked
about.
We
got.
We
got
a
sort
of
official
consensus
amongst
the
amongst
the
omar
community
around
establishing
a
python
ci
dependency,
so
giving
us
the
ability
to
use
python
during
the
the
well
to
do
things
during
our
ci
pipeline
that
the
the
main,
the
main
consequence
of
this
is
that
downstream
consumers
of
omar
will
now
need
to
have
python
installed
in
order
to
be
able
to
successfully
build
omr.
A
So
right
now,
even
though
we've
we've
said
that
there's
a
python
dependency
unless
you're
building
something
like
jetbuilder,
it
doesn't
really
get
exercised,
but
we
want
to
make
that
a
little
bit
more
solid,
so
that
so
that
there
would
be
problems
in
case
the
the
downstream
project
doesn't
have
python,
and
the
reason
for
that,
of
course
is.
Is
we
want
to
start
exploring
using
python
for
various
things
for
generating
things
during
compile
time
that
and
build
time
that
that
we
don't
right
now.
A
Looking
ahead
for
2022
again,
as
I
said
before,
there
isn't,
this
isn't
necessarily
an
exhaustive
list.
It
is
a
and
it
is
somewhat
aspirational
in
in
some
respects,
but
it
is
sort
of
a
good
estimate
of
what
we'd
like
to
do
as
of
as
of
today.
But
you
know,
things
will
change
throughout
the
year
as
we've
seen
in
years
past.
So
this
should
give
us
a
good
guideline
for
where
we
are
going
at
least
for
the
compiler.
A
A
Some
of
the
major
back-end
work
that
needs
to
get
done
this
year
is
full
support
for
for
intel
avx.
That
is
that
already
started
last
year.
It's
just
going
to
continue
on
into
this
year.
It's
a
it's
a
fairly
large
piece
of
work.
It
needs
some
re-architecting
of
the
the
intel
back-end
to
support
the
different
instruction
formats
register
assignments.
You
know
encoding.
That
kind
of
thing,
so
a
lot
of
stuff
has
to
happen
there
still
and
similarly
on
the
other
architectures.
A
Some
of
this
is
going
to
get
surfaced
to
the
project
fairly
soon,
but
I
know
that
behind
the
scenes
there's
some
work
on
structuring
the
information
that
is
going
to
be
documented
and
make
it
easier
to
consume
easier
to
follow
and
figure
out
what
what
what
some
of
the
areas
are,
that
need
to
be
documented
that
that
aren't
currently.
So
I
expect
that
we're
going
to
have
some
some
discussion
on
that
in
the
architecture.
A
Meetings
coming
up
in
the
next
in
the
next
couple
of
months,
or
so,
as
I
said
before,
mark
will
continue
to
work
on
the
jit
builder,
2.0
or
2.x.
Api
he's
got
some
ideas
there
on
what
what
he
had
in
mind
for
2.0
and
what
would
work
better
for
two
point
x.
So
I
understand
he's
working
on
that
and
again
we
can
expect
to
see
something
at
least
to
talk
about
sometime
sometime
this
year.
A
Similarly,
the
based
on
some
of
the
discussion
that
happened
last
year,
we
did
make
some
progress
on
the
compiler
api.
I
did
have
some
ideas
that
I
started
to
prototype
as
well.
I
just
need
to
continue
to
carry
those
forward
and
getting
into
something
that
can
actually
get
into
the
code
base
so
that
we
can
start
to
start
to
reshape
things.
So
I
expect
that
I
may
have
some
opportunity
to
make
some
of
those
enhancements
sometime
this
year
as
well.
A
It
can
really
do
so.
We've
set
a
goal
for
this
year
to
to
really
break
down
some
of
those
bigger
items
into
smaller
pieces
that
that
people
can
take.
Ideally,
it
would
be
something
that
you
know
can
be
can
be
implemented
and
perhaps
tested
and
and
and
turned
around
within
a
matter
of
a
couple
of
days,
as
opposed
to
something
that
will
be
ongoing
for
several
weeks.
So
the
goal
is
to
really
break
things
down
into
smaller
chunks
like
that,
so
that
so
we
can
continue
to
make
forward
progress.
A
And
on
the
infrastructure
side,
something
that
comes
up
all
the
time
is
automatic
copyright
verification.
I
think
we
just
need
to
do
that.
It's
it's
a
bit
of
a
a
thorn
in
our
side,
so
I
know
that
there
were
some
stumbling
blocks
to
getting
that
done,
but
I
think
that
we
can
certainly
work
out
some
kind
of
a
an
omar
specific
solution
to
that
and
then
just
move
forward
because
well
we
have
to
the
other,
is
the
linter?
A
The
linter
needs
to
be
updated
because
it
was
originally
written
to
run
on
ubuntu
16
and
used
a
particular
version
of
clang
that
was
available
there.
The
linter
as
it
is
right
now
does
not
run
on
with
with
newer
versions
of
newer
versions
of
clang.
It's
just
a
matter
of
re
re-implementing,
some
of
the
apis
that
it's
using.
A
So
that's
not
a
big
thing,
but
the
the
reason
that
but
I'd
like
to
take
the
opportunity
to
use
the
or
to
well
to
use
the
linter
to
also
enforce
the
some
of
the
compiler
api
decisions
that
we
made
last
year.
So
we
talked
about
using
some
some
code
attributes
to
describe
the
the
properties
of
extensible
classes
and
we
can
use
the
lynch
to
check
those
those
things
as
well.
We
can
also
do
you
know
we.
A
We
can
also
relax
some
of
the
restrictions
that
we've
had,
that
we
have
right
now
right
so
so,
for
example,
there's
you
know
there
may
be
some
opportunities
where
self
isn't
required
or
there's
opportunities
where
certain
methods
are
are
are
never
considered
to
be
extensible
like
where
you
get
the
compilation,
object
or
the
code
generator
object.
Things
like
that.
A
A
A
A
So
we'll
see
what
we
can
come
up
with
for
for
this
year
and,
as
I
mentioned
before
about
python,
we
really
want
to
incorporate
the
some
sort
of
python
dependency
into
the
devops
pipeline
to
to
really
solidify
that
solidify
that
dependency
and,
of
course,
before
we
do
that.
There's
a
there's
the
there's
the
communication
aspect
that
has
to
go
along
with
that
to
give
known
downstream
consumers
a
heads
up
that
that
there
are
some
some
work
that
they
may
need
to
do.
A
So
that's
all
I
have
on
the
on
the
list
for
for
for
2022..
I
know
that
there's
others
that
people
are
going
to
be
working
on
that
that
that
are
not
on
this
list.
I
thought
it
put
together
just
a
very
high
level
structure
of
the
direction
where
some
of
these
things
are
going
certainly
want
to
open
it
up
now
for
any
questions
that
anybody
has
or
any
comments
on
the
work
or
or
thoughts
in
the
direction
or
any
other
ideas
that
that
people
have
for
the
for
the
project.
A
B
I'll
say
a
few
more
words
about
did
builder
2.
I
guess,
if
that's
interesting
enough,
the
so
the
pull
request
that
I
opened
last
year
with
the
initial
contribution
I
actually
just
closed,
and
the
reason
for
that
is
that
this
state
of
the
code,
that's
in
that
pull
request,
is
actually
fairly
almost
archaeological
at
this
point
compared
to
what's
in
my
private
repo.
So
what
I'm?
B
What
I'm
going
to
do
is
commit
in
front
of
all
of
you
here
to
come
back
by
the
end
of
february
and
I'm
gonna
present
I've
been
making
some
good
progress
on
this.
You
know
post
the
new
year,
which
is
kind
of
the
best
time
I
get
to
work
on
things,
and
you
know
some
of
the
some
of
the
grander
organization
of
builder
2
has
started
to
settle
in
my
head.
B
There's
still
some
open
questions
there,
but
I
think
I'm
more
ready
to
start
having
a
real
conversation
around
you
builder
2
and
where
it's
going
so
I'll
schedule
that
for
probably
the
last
well
actually
given
the
frequency
of
these.
I
guess
it's
this,
the
first
architecture
meeting
in
march-
maybe
I'll
schedule
it
for
if
that
works.
B
If
anyone's
curious
to
learn
anything
in
the
meantime,
you
can
always
reach
out
and
chat
with
me.
I'm
happy
to
talk
to
you
about
it,
nothing,
nothing
secret
about
it.
Just
kind
of
I
don't
want
to
keep
bothering
people
with
here's.
What
it
looks
like
this
week
and
then
next
week
come
back
and
say:
here's
what
it
looks
like
this
week.
A
A
Okay,
well,
if
there's
nothing
else,
I
guess
last
call
for
for
any
feedback,
so
I
don't
want
to
keep
anybody
any
longer.
Just
wanted
to
kick
off
the
year
again
with
the
you
know,
with
the
retrospective
and
and
a
bit
of
a
direction
going
forward.
So
I
think
that
there's
certainly
the
opportunity
to
land
a
lot
of
really
exciting
things
this
year
and
move
the
technology
base
forward.