►
From YouTube: OMR Architecture Meeting 20210318 1804
Description
Agenda:
* Defining an API to the OMR Compiler (#5858) [ @0xdaryl ]
A
A
What
I
was
thinking
that
we
could
do
is
to
I'd
like
to
hear
everybody's
thoughts
on
the
topic
and
and
perhaps
to
brainstorm
some
ideas
on
on
what
it
is
that
we
need
to
do
and
perhaps
even
share
some
experiences
from
from
those
that
have
tried
to
extend
the
compiler
in
certain
ways.
So
let
me
just
back
out
of
this
for
a
sec
and
I
will
share
something
different
share.
My
browser.
B
B
A
Okay,
so
let's
have
some
talking
points
in
this
issue.
Five,
eight
five
eight
so
wanted
to
talk
today
about
defining
the
an
api
for
the
compiler
there
are.
There
are
some
good
reasons
for
for
needing
to
do
this.
One
is
as
the
number
of
projects
that
are
consuming
omr
starts
to
grow.
It's
not
a
huge,
it's
not
a
huge
number
right
now,
but
but
certainly
there
are
a
few
projects
in
the
works.
A
At
some
point,
these
projects
are
going
to
require
that
you
know
they're
going
to
want
to
consume
omr
from
the
wild.
So
there's
going
to
be
some
expectation
on
stability
of
the
of
the
of
omr
that
they're
consuming
going
going
forward.
So
we
started
a
release
process
with
omr
in
2019
and
we
basically
did
a
sort
of
a
token
release,
but
in
in
late
2019,
but
we
haven't
really
done
anything
with
that.
Since
then,
the
for
that
particular
release.
A
We
had
said
that
only
a
few
components
of
omr
were
ready
to.
You
know
declare
some
stability
on
their
api,
and
that
was
the
port
library
and
the
garbage
collector,
but
the
jit,
compiler
and
jit
builder
were
not
part
of
that,
and
even
though
we
are
functionally
stable,
those
components
are
functionally
stable.
A
A
So
so
that's
that's
one
way
of
accessing
the
compiler,
the
other.
It's
sort
of
a
reflection
of
the
fact
that
this
is
a
rather
complicated
interface
and
many
projects
that
would
like
to
consume.
That
would
like
a
jet,
don't
want
to
go
through
that
entire.
Don't
want
to
expose
all
that
complexity
to
them.
A
So
jit
builder
itself
has
got
a
its
own
interface
that
is
exposed
to
a
consumer
and
the
underlying
compiler
interface.
Isn't?
Actually
you
don't
have
to
care
about
that?
You
don't
have
to
worry
about
that.
You
only
need
to
care
about
what
did
builders
offering
you
so
there's
two
different
levels
of
of
interface
here
that
we're
talking
about
and
one
thing
would
be
to
perhaps
consider
you
know
splitting
these
like.
Are
these
two
separate
conversations
or
or
is
this
or
are
we
talking
about
them
together?
A
And
then
perhaps
even
the
third
option
is
to
not
even
consider
any
of
that
and
then
just
go
with
the.
How
do
you
actually
invoke
the
compiler?
What
what
what's
the
minimum
thing
that
you
need
to
invoke
the
compiler
and
what
the
like
your
domain,
initialize
method,
on
a
compile,
method
and
and
some
means
for
getting
the
the
compiled
method
back-
is
that
all
the
api
is
expected
to
be
so
I'm
gonna
just
stop
there
for
a
sec
to
see.
A
If
anybody
has
any
immediate
opinions
on
that,
I
I
think
actually
it
is
a
good
place
to
stop
and
get
get
other
input
on
what
they
think
of
the
compiler,
not
necessarily
think
about
jit
builder.
At
this
point,
but
just
the
compiler
itself,
are
there
any
thoughts
on
what
I
just
said
or
other
different
ideas
on
how
we
can.
C
C
So
off
the
top
of
my
head,
just
thinking
about
the
options
you
were
mentioning
daryl
for
how
we
can
go
about
defining
the
api.
I
think
the
most
straightforward
approach
for
us
is
probably
to
look
what
you
were
saying
about.
Looking
at
what
what
what
methods
we
have
available
currently
in
the
classes
and
figuring
out
kind
of
what's
the
minimum
set
of
things
you
need
in
order
to
build
a
compiler,
I
think
that's
probably
the
least
effort
for
us
simply
because
we're
already
starting
from
what
we
have.
C
I
guess
there
is
a
risk
in
there
in
that
we
are
creating
an
api
based
on
an
implementation,
so
it
biases
what
the
api
is
going
to
look
like
if
we're
not
careful
right,
because
it
would
be
very
easy
to
then
create
an
api
that
reflects
some
of
the
assumptions
that
we
make
currently
in
the
implementation
of
the
compiler
and
then
later
on.
If
we
figure
out
that
actually
those
imp,
those
assumptions
are
problematic
either
they're,
not
general
enough
or
we
need
to
change
them.
A
Were
you
thinking
about
applying
that
ideal
api
on
the
component
level,
or
is
this
something
that's
a
bit
higher
than
that?
So
I
mean
it's
true
that
the
compiler
is
composed
of
many
different
individual
components,
various
classes,
I
think
you
know
it
must
be
in
the
dozens
of
of
classes
that
that
need
to
get
implemented
or
may
need
to
get
get
implemented.
C
It
it's
kind
of
something
that
well,
you
would
have
to
do
it
incrementally
somehow,
but
without
getting
into
how
you
would
actually
do
it.
My
thinking
is
it's
something
that
we
would
essentially
have
to
apply
in
a
way
at
all
levels,
so
we
would
start
off
with
applying
it
just
with
the
different
compo,
whatever
high
level
components
of
the
compiler.
We
want
for
things
like
initializing,
the
compiler,
shutting
down
starting
a
compilation,
getting
back
the
compiled
method
and
then
applying
the
same
idea,
one
level
down.
C
A
Yeah
I
mean
that
sounds.
That
sounds
like
a
good
plan.
I
think
the
one
of
the
challenges
that
we
have-
and
I
think
you've
already
kind
of
addressed
this-
is
that
we
we
don't
really
have
any
kind
of
api
at
the
moment
so
like
there's
no
top
to
start
going
down
from,
I
think
we
would
have
to
define
those
layers
like
what
is
the
invocation.
What
is
the
initialization
interface?
What
is
the?
C
C
There
are
strategies
for
working
around
that
by
basically
adding
interfaces,
be
more
interfaces
between
things
with
things
like
the
facade
pattern,
so
that
you
hide
the
pieces
you
don't
want
to
show,
but
yes
it
it.
We
would
be
creating
a
new
api
and
retrofitting
it.
On
top
of
our
existing
implementation.
D
Does
anyone
know
of
a
compiler
api
that
can
evolve?
That
is
general
enough
that
it
evolves
with
the
implementation?
I'm
pretty
sure
the
quintessential
examples.
Llvm
and
gcc
are
probably
not
in
that
category.
Right,
like
I
know,
lvm
changes
its
api
for
various
things
at
times.
I
certainly
in
the
details
anyway,
yeah
yeah
you're,
right
from
major
release
to
major
release.
Anyway,
I
think
that
the.
C
D
D
D
C
But
there's
also
that
I
do
want
to
also
acknowledge
the
fact
that,
just
because
we
can't
keep
the
api
stable
doesn't
mean
we
will
right
right.
So
you,
a
project,
could
choose
to
change
its
api
because
it
decides
that
whatever
api
it
used
to
have
is
very
error
prone
for
its
users.
So
they
decide
to
deprecate
it
and
replace
it
with
a
new
api
right.
C
Yeah,
so
I
guess
then
the
point:
is
you
want
to
limit
those
kinds
of
changes
to
be
nice
to
the
user?
So
if
you
don't
have
a
if
your
api
is
very
tied
to
your
implementation
right,
then
any
sort
of
change
you
make
to
how
things
work
internally
is
going
to
require
public
api
changes
and
things
are
going
to
be
disturbed
all
the
time.
D
I
mean
I
understand
the
principle
and
and
agree
with
the
basic
direction
I
mean
I
mean
who's
going
to
argue
against
it
right
really
yeah
you're
trying
to
make
a
better
world
for
your
consumers.
That's
basically
the
enough
of
it
right
so
that
there
we
have
the
flexibility
to
change
the
implementation,
and
yet
the
api
is
more
or
less
stable,
so
our
consumers,
all
they
get,
is
you
know
the
hopefully,
improvements
made
in
in
the
implementation
characteristics
without
having
to
adjust
their
code
to
deal
with
changes
in
the
api
as
much
as
possible.
D
D
Well,
maybe
before
I
go
there,
so
we
also
have
a
very
intense
current
consumer
who's
used
to
having
all
of
the
implementation
level
hooks
that
it's
using
right
now
right,
so
openg9
obviously
has
a
very
tight
integration
with.
Well,
I
mean
it's
a
separate
project
still,
but
it
it's
it's
the
most
broad
user
of
the
current
public,
publicly
exposed
methods
and
data
structures
that
are
inside
the
omar
compiler
right.
D
I
hesitate
to
call
that
an
api,
even
though
it
is
kind
of
at
some
level
the
api
of
the
compiler,
but
but
we
we
have
to
understand
how
we
would
get
to
a
new
api
without
damaging
the
existing
kind
of
dependency
that
open
g9
has
on
the
existing
public
interfaces,
which
is
gonna,
be
a
challenge.
I
have
to
be
candid
about
that,
so
I
guess
I'm
and
and
sort
of
putting
that.
D
D
So
you
know
there's
value
to
it,
but
there's
kind
of
there's
going
to
be
a
knee
of
a
of
the
curve,
and
I
kind
of
wonder
if
maybe
what
we
should
start
with
is
something
more
like
what
what
daryl's
got
written
here
like
sort
of
defining
like
we
lack
a
lot
of
sort
of
core
documentation
on
what
are
the
main
classes
and
what
are
their
purposes
and
what
are
the
boundaries
between
them?
What
are
their
areas
of
responsibility?
What
are
their
life
cycles?
D
D
D
So
one
way
of
looking
at
this
is
that
jit
builder.
Is
that
api
right,
because
it
implements
basically
the
minimum
amount
of
stuff
that
you
need
to
do
in
order
to
create
a
compile
like
instantiate,
the
omr
compiler,
to
be
able
to
meaningfully
do
stuff?
It
provides
a
set
of
apis,
which
I
tried
to
design,
and
at
least
I
know
it's
changed
as
well,
but
tried
to
design
in
a
way
that
could
be
more
sort
of
stable
from
release
to
release
trying
not
to
make
them
implementation
specific
type
exposures.
D
A
Yeah,
I
I
I
mean
certainly
looking
at
jit
builder,
you
know
the
api
seems
to
be
it.
It
seems
to
be
more
and
with
all
credit
to
you
fairly
well
thought
out,
and
you
know
at
least
with
an
attempt
of
architecting,
something
that
would
be
of
architecting
an
api.
So,
and
it's
I
mean
at
the
moment
it
doesn't
have
a
lot
of
consumers.
So
there
isn't.
You
know
it
there's
less
opinions
on
how
that
api
needs
to
evolve,
to
match
some
existing
implementation
of
something.
D
D
A
D
There
are
other
requirements
from
jit
builder
consumers
that
I
think
would
benefit
expanding
certain
other
aspects
of
the
chip.
Builder
api,
like
the
initialization
sequence,
howdy
like
right
now,
that's
actually
one
of
the
places
that
that
does
expose
a
little
bit.
It's
an
optional
part,
but
you
can
specify
tr
options
as
part
of
your
initialization
call
right.
That
has
nothing
to
do
with
jitbuilder.
C
A
A
Okay
from
the
from
the
okay
and
then
going
down
a
level
to
the
compiler,
I
mean,
I
think
that
I
mean
it
would
there's
sort
of
we
can
go
around
in
circles
on
this
because
you
know
it
would.
It
would
be
nice
to
actually
have
the
core
components
of
the
compiler,
the
building
blocks
of
the
compiler.
If
you
will,
you
know
clearly
defined
and
and
documented
and
and
as
language
agnostic
as
as
possible.
A
I
I
think
that
if
we
had
something
like
that,
that
would
form
the
basis
of
maybe
taking
the
next
step
with
the
compiler
and
and
perhaps
putting
like
defining
a
higher
level
api
on
on
that,
but
I
think
just
like
for
all
these
different
components
that
we
have
a.
What
are
the
components
that
we
think
are
are
required
for
a
consumer
to
consume
and
and
how
do
they?
How
do
they
work?
What
do
the
apis
look
like
and
what
are
they
supposed
to
do
and
how
do
they
interact
with
other
things?
D
Okay,
I
was
just
gonna
say
I
I
think
you'll
have,
I
think,
we'll
have
trouble
defining
a
public
api
before
we've
defined
what
the
sort
of
boundaries
are
of
those
major
components.
I
think
that's
kind
of
a
fundamental
aspect
of
being
able
to
define
the
api
is
you
have
to
first
define
the
the
elements
of
that
api.
A
C
E
E
D
Yeah,
I
agree
with
that
too.
Actually,
you
made
me
think
of
something,
as
you
were
talking
that
they're
they're
kind
of
different
parts
to
the
api
that
different
sort
of
use,
scenarios
I'll
say,
use
loosely
compiler
implementers
people
who
would
implement
changes
to
a
compiler,
I
guess
or
add
things
to
a
compiler-
would
do
right
like
there's
there's
some
people
are
trying
to
build
a
different
front
end
basically
they're
trying
to
incorporate
the
compiler
into
another
runtime
system
and
and
use
it
to
generate
code.
D
Some
people
are
trying
to
add
a
code
generator
and
understand
what
they
need
to
do
in
order
to
to
add
code
generator
for
a
platform
that
isn't
currently
supported
those
kinds
of
like
there's
kind
of
different
classes.
I
guess
of
of
things
like
I
mean
you
could
bundle
it
all
up
into
one
single
api,
but
maybe
there's
value
in
thinking
about
those
kinds
of
yes
user
stories
for
lack
of
a
better
word
phrase.
D
D
Yeah,
I
think
that
makes
sense
too,
like
adding
an
optimization,
for
example,
doesn't
have
to
touch
all
of
that
life
cycle,
initialization
code
generator.
You
know
extending
instruction
and
all
of
that
kind
of
corp,
whereas
if
you're
doing
a
code
generator.
Obviously
you
need
to
understand
very
well
how
how
instruction
works,
how
the
machine
works,
how
all
of
the
register
dependency,
stuff
works
and
all
of
the
other
kind
of
you
know,
lower
level
bits
and
bobs
registers
and
themselves.
A
Those
are,
these
are
good
points
on
the
topic
of
extensible
classes,
so
I
did
want
to
mention
that
so
we've
we've
had
the
no
we've
introduced
the
notion
of
extensible
classes
into
the
omr
compiler.
For,
for
a
variety
of
reasons,
I
I
will
admit
that
we
often
hear
that
there's
potentially
some
confusion
around
them.
A
There
was
a
research
project
that
tried
to
study
the
use
of
extensible
classes
and
they
looked
at
all
the
requirements,
the
project,
all
the
constraints,
things
like
that
and
the
conclusion
was
there
wasn't
there
was
no
recommendation
of
anything
actually
better
that
would
that
would
solve
it.
It's
not
saying
that
extensible
classes
are
the
best,
but
it's
there
wasn't
any
other
clear
alternative
that
would
address
the
needs
that
we
have
so
the
reason
I'm
saying
this,
though,
is
that
going
forward.
A
It
seems
like
extensible
classes
is
the
main
means
that
we're
going
to
have
to
provide
extensions
to
many
of
these
classes,
core
classes
that
will
be
part
of
the
sort
of
public
api,
so
things
like
node
or
compilation,
or
the
instruction
class
things
like
that,
they're
going
to
use
this
notion
of
extensible
classes,
and
you
know,
certainly
if
anybody
has
alternative
thoughts
on
extensible
classes.
You
know
you
know
soon
would
be
the
right
time
to
to
to
raise
that.
A
But
if
we're
going
to
go
forward
with
extensible
classes,
I
think
that
there
are
some
ways
that
we
can
make
some
changes
to
them
to
perhaps
make
them
more
like
an
api
or
more
api.
Ready,
like
one
of
the
challenges
that
we
have
right
now
is
is
enforcing
what
it
is
that
we
want
like
controlling
what
it
is
you
want
to
make
extensible
or
not.
A
So
there
isn't
really
a
way
that
we
have
to
say
that
you
know
this.
This
particular
api,
this
particular
method.
Sorry
this
particular
function.
I'm
going
to
allow
you
to
extend,
but
in
your
project
there
isn't
this
sort
of
way
of
marking
it
public.
Basically,
everything
is,
is,
is
public,
so
we
would.
A
I
would
think
we
would
almost
need
to
introduce
some
kind
of
I'm
going
to
say
just
sort
out
this
as
a
suggestion,
not
necessarily
the
right
thing
to
do,
but
if
we
had
some
kind
of
an
attribute
system
where
a
c
plus
attribute
system
where
you
could
define
or
the
project
the
omr
project
could
define.
These
are
the
things
that
I
want
to
expose
as
as
possible
extension
points,
and
these
are
things
that
are
not.
A
Then
I
think
that
would
go
a
it
would
be.
It
would
be
helpful
to
control
the
the
api
as
we
as
we
go
forward.
I
think,
because,
right
now
everything
is
public
so
and
if
we
did
introduce
those
kinds
of
attributes,
we
could
actually
have
like
broaden
the
tooling
that
we
use
the
linting
technology
that
we
use
to
check
that
the
apis
are
being
used
properly
or
these
extension
points
are
being
used
properly
and
the
technology
that
we
have
that
the
clang
tooling
that
we
developed.
A
A
So
that's
really
the
point
that
I
wanted
to
raise
about
extensible
classes.
I
think
it's.
It
seems
to
be
the
strategic
technology
that
we're
using
and
we're
going
to
be
using.
But
I
think
if,
if
that's
going
to
be
the
case,
then
we
have
to
harden
it
a
bit
with
potentially
some
compiler
extensions
to
those
apis
to
to
to
make
things
a
bit
easier
to
to
do,
and
we
could
also
do
things
like
we
can
set
aside.
A
You
know
certain
functions
to
be
known
to
be
not
extensible
and
therefore
they
won't
require
the
the
self
methods
right.
So
simple,
getters
and
setters
for
things
like
the
compilation,
object
or
the
code
generator
object
or
the
or
you
know
other
things
like
that
or
memory
that
aren't
very
unlikely
to
be
extended.
D
D
C
B
A
A
I
don't
think
that
ever
really
went
anywhere,
but
the
the
effort
that
was
put
into
that,
though,
suggested
that
it
was
that
it
was
possible
to
do
so.
I
think
you
know
you're,
maybe
raising
a
good
point
about
about
some
of
this
as
well,
and
that,
just
in
terms
of
the
to
make
things
more
consumable
and
to
make
things
easier
to
extend,
perhaps
there
is
some
tooling
that
could
be
developed
to
assist
consuming
projects
with
making
their
own
customized
extensions.
A
You
know,
perhaps
by
something
that
just
goes
and
creates
a
skeleton
class
for
you
that
does
all
the
right
that
inserts
the
code
in
the
right
places
and
and
includes
the
right
files
and
puts
the
right
defines
in
the
correct
places
that
we
would
expect
so
so
yeah,
that's
a,
I
think,
that's
a
good
suggestion.
James.
B
A
I
mean
yeah,
I
mean
the
the
extensible
classes
is
a
solution
for
like
static
polymorphism,
but
we're
not
precluding
the
use
of
at
the
moment.
We
don't
preclude
the
use
of
dynamic
polymorphism
in
the
compiler
if,
if
that's
the
most
sensible
thing
to
do
so,
I
think
what
you
see
in
the
optimizer
hierarchy
is
a
mixture
of
both.
You
may
have
a
a
base
class,
that's
statically,
that's
composed
for
static
polymorphism
and
then
you've
got
a
dynamically
polymorphic
built
underneath
it
and
same
thing
with
the
instruction
class.
A
It's
like
that
as
well,
but
so
that
I
think,
should
be
allowed.
If,
if
you're
asking
about
you
know
multiple
inheritance
with
extensible
classes
within
the
extensible
class,
like
the
the
components
of
the
extensible
class,
I
think
that's
going
to
be
a
little
bit
difficult
to
to
implement.
I
know
we
gave
we
did
get
some
thought
at
one
point,
but
we
couldn't
really
get
that
to
work
in
a
practical
way.
A
However,
there
are
other
parts
of
the
compiler
that
aren't
at
the
moment
extensible
or
they're,
not
extensible
classes,
yet
they
are
things
that
downstream
projects
can
consume
as
well.
So
I
guess
I
just
wanted
to
mention
that
when
we're
talking
about
things
that
could
be
publicly
consumed
from
the
compiler
they're,
not
all
going
to
be
extensible
classes
or
maybe
they
should
be.
I
don't
maybe
that's
a
that's
an
open
question,
whether
or
not
anything
that's
consumable
from
the
compiler
should
be
should
be
extensible.
I
I
my
feeling
is:
no.
D
A
Yeah,
that's
that's
true.
There
is
a
certain
and-
and
it
also
yeah
I
mean
you-
a
downstream
project
can
feel
comfortable
in
the
fact
that
any
sort
of
public
api
any
of
the
apis
can
be
extended
and
customized.
The
way
that
that
they
want.
I
guess
the
thing
that
I'm
that
like
there
is
a
certain
overheads
with
extensible
classes
and-
and
I
don't
mean
a
performance
overhead-
I
mean
just
the
the
implementation
overhead
with
these
extensible
classes.
A
A
So
what
exactly
is
the
operation
of
each
of
the
op
codes
in
that?
What
is
the
exp?
What
are
the
expected
inputs?
What
what
is
the
expected
output?
How
can
a
you
know?
What
is
the
role
of
a
language
environment
in
in
the
interpretation
of
that?
Are
there
means
of
changing
the
semantics
or
are
the
semantics
exactly
the
same
for
every
every
il?
A
A
What
we
call
a
front-end
interface
and
it's
it's
changed-
I
mean
certainly
between
the
the
time
that
the
the
code
was
closed,
source
and
the
time
that
it
got
open
sourced
it
changed
quite
a
bit
and
it
got
whittled
down
to
to
something
much
smaller
and
in
fact,
this
whole
compiler
environment
class
sort
of
built
up
from
that.
However,
that
work
never
really
got
completed.
A
B
A
If
the
classes
are
going
to
be
part
of
the
api,
then
obviously
we
need
to
document
those
consistency
would
be
a
a
good
goal
to
achieve,
as
well
so
having
a
consistent
way
of
documenting
all
the
classes,
all
the
methods,
all
the
data
structures,
things
like
that
would
be
useful
to
do.
I
also
think
that
you
know,
maybe
if
it
was
possible,
that
there
was
some
way
that
we
could
highlight
what
the
public
members
actually
were,
the
the
parts
that
are
consumable.
A
A
A
A
So
I
think
there
there
may
be
some
ideas
to
to
distill
from
from
that
discussion,
to
help
shape
this,
to
help
make
this
a
more
focused
discussion
going
forward.
So
I
mean
thanks
for
the
the
opinions
that
were
that
were
expressed
and
and
some
of
the
ideas
there.
So
perhaps
one
of
the
next
steps
here
is
to
is
to
do
that.
Work
and
and
and
distill
some
of
those
ideas
and
to
try
to
form
something
a
little
bit
more
concrete.