►
From YouTube: OMR Compiler Architecture 20190225
Description
Agenda and slide deck: https://github.com/eclipse/omr/issues/3607
A
Okay,
so
welcome
everyone
to
this
week's
compiler
architecture
meeting.
So
this
week
we
have
a
talk
from
dr.
Nadia.
The
University
of
Alberta
who's
been
looking
at
how
to
make
some
of
the
technology
that
we
have
more
extensible
and
consumable
by
other
by
other
projects.
So
I
believe
she
has
a
presentation
that
she'll
go
through
so
I'll
just
turn
things
over
to
dr.
net.
Okay,.
B
Forever,
thanks
Darrell
hi
everybody,
I'm
Sara
I'm,
an
assistant
professor
at
the
University
of
Alberta,
and
part
of
my
research,
is
involving
looking
into
configurable
software
or
what's
called
software
product
lines.
So
when
you
have
to
cater
to
multiple
requirements,
multiple
platforms
have
features
that
are
optional,
that
you
enable
or
disable
them
that's
all
kind
of
got
into
this
working
with
the
Omar
team.
So
let
me
start
by
so
that
today
we're
going
to
talk
about
Omar's
design
and
some
of
the
things
some
of
the
problems
we
found
with
it.
B
Solar
has
what
we
call
free
variability
points,
so
you
need
to
select
an
architecture
or
like
oh,
the
first
specific
architecture,
the
language,
for
example,
if
you're
targeting
Java
or
Ruby,
and
the
operating
system
you're
running
on.
There
is
also
considerations
like
making
sure
that
the
any
design
that
you
have
has
good
compile
time
performance.
You
don't
want
to
wait
forever
for
your
code
to
compile,
has
a
low
memory
footprint.
B
So
when
running
that
code,
the
produced
code
has
a
low
memory
footprint
and
the
runtime
performance,
obviously,
and
a
main
criteria
is
that
the
design
should
be
language
agnostic,
so
in
the
end
all
are
supposed
to
be
supporting
multiple
languages
and
extensible
for
those
languages,
so
I
mean
probably
everybody
here
already
knows
so.
The
current
implementation
mechanism
used
for
supporting
the
school
is.
B
Classes
through
static
polymorphism,
so
you
have
the
different
namespaces.
You
have
the
same
costs
in
every
namespace.
You
have
things
like
the
connectors,
which
are
type
def
to
the
different
classes
and
the
different
namespaces.
And
then
you
have
your
concrete
class
or
TR
that
happens
in
the
TR
names.
B
This
was
this
is
the
current
state
of
things
and
what
happened
just
to
give
you
a
bit
of
background
is
there
was
the
main
problem
or
maintain
that
people
had,
which
was
using
self
in
extensible
classes,
and
so
what
happened
is
about
two
years
ago
that
are
less
than
two
years:
Matthew
who's,
not
with
idea
Maclaurin
now,
but
who
worked
and
Almar.
He
gave
a
presentation
about
how
all
mar
worth
and
it's
kind
of
related
to
things.
I
know
about
how
the
group.
D
B
See
I
was
mainly
working
with
linux.
Kernel
was
different
if
stuff
and
so
on,
and
so
we
started
talking
about
how
the
current
implementation
mechanism
is
hard.
People
don't
understand
the
self
usage
and
so
on
and
along
with
now
Shelley
and
Robert,
who
were
working
with
after
Matthew
left
and
a
team
of
students
from
the
U
of
A.
B
So
just
to
give
you
some
background
of
the
kind
of
work
we've
done
so
far,
so
the
first
thing
was
samer,
who
was
the
master
student
working
on
this
project?
He
built
a
static
analysis
tool
called
all
more
statistics
which
basically
gave
different
information
about
the
polymorphism
going
on,
such
as
where
a
function
is
overridden
across
the
different
architectures.
So
a
bit
of
to
try
to
understand
where
this
function
is
overridden,
where
it's
used
and
things
like
that,
and
then
we
moved
on
to
actually
investigate
whether
migrating
to
dynamic
polymorphism
is
feasible.
B
So
one
of
the
options
of
removing
the
self
problem
is
to
actually
use
dynamic
polymorphism.
Now
the
main
concern
there
was
the
performance,
but
this
was
never
actually
empirically
evaluated,
so
we
started
working
towards
that.
It's
a
bit
of
a
slow
process
because
you
actually
have
to
do
a
lot
of
edits
in
the
code
and
get
things
to
work
correctly.
So
what
we
did
was
we
converted
five
classes
to
use
dynamic
polymorphism
and
based
on
the
first
class
code
generator,
which
is
the
biggest
class.
B
We
ran
some
benchmark
like
very
early
benchmarks,
and
these
are
two
benchmarks
to
day-trader,
benchmark
and
odm
benchmark,
and
these
experiments
are
so
far
only
on
the
based
on
the
code,
generator
class
and
x86
architecture.
But
we
noticed
there
was
no
significant
change
in
either
direction.
So
this
is
all
like
the
difference
and
means
there
is
within
the
confidence
interval.
So
there's
really
no
significant
changes
either
for
against
using
dynamic
polymorphous.
B
So
this
was
kind
of
good
news.
Okay,
maybe
dynamic
polymorphism
is
the
solution,
but,
as
I
got
to
understand
more
and
more,
what
is
happening
in
all
more
and
how
it
works.
I
realized
that
they
have
a
polymer
for
the
monly
selves
part
of
the
current
problems
and
challenges
faced
in
Almar.
So,
yes,
it
will
remove
the
use
of
cells,
but
that's
about
it.
B
It
will
not
solve
any
of
the
other
problems
in
the
design,
and
so
what
I
wanted
to
do
at
this
point
before
going
ahead
and
changing
like
the
whole
code
base
or
coming
up
with
something
new,
is
to
actually
understand
what
are
the
current
problems
being
faced
and
what
are
maybe
constrains
for
any
potential
redesign
of
orlimar
so
that
we
don't
go
ahead
and
do
something
that
is
then
a
disaster
or
that
ends
up
like?
Oh,
no,
you
didn't
think
about
this
or
something
like
that,
and
the
plan
is
after,
like
eliciting.
B
The
problems
and
constraints
is
to
explore
both
the
literature
related
to
configurable
software
and
software
product
lines,
and
look
at
all
so
similar
implementations
in
the
open-source
community
and
try
to
come
up
with
here
are
two
to
three
recommendations
that
either
satisfy
all
your
requirements
or
we
lose
this
requirement
and
to
actually
have
perhaps
a
student
that
can
try
to
do
this
migration
and
see
how
it
affects
me.
So
what
I
did
is
I
did
an
interview
study
with
some
of
the
current
developers
who
contribute
to
our
use
Omar,
particularly
six
developers.
B
So
what
I
want
to
do
in
this
presentation
is
I'm
going
to
present
these
problems
that
I've
identified
and
my
goal
is
I
want
to
get
feedback
about
them.
Elaboration,
perhaps
I
misunderstood
something
or
that
there's
actually
something
that
didn't
come
up,
that
some
people
are
interested
in
and
also
to
get
a
priority
list
of
these
requirements.
B
B
B
Some
of
the
requirements
are
my
interpretations,
trying
to
put
together
like
kind
of
the
complaints
that
I
heard
and
putting
them
in
upon
the
requirement
for,
and
at
this
point
we
don't
have
the
solution.
Yet
the
point
is
after
coming
up
with
this
prioritized
list
of
requirements
is
to
go
and
explore
the
solution
and,
by
the
way,
I'm
happy
to
take
questions
in
the
middle
of
interrupt
at
any
point.
So
don't
feel
like
you
have
to
wait
till
the
end.
B
Okay,
so
before
I
go
into
the
problems,
I'll
start
on
a
more
positive
note.
So
some
of
the
comments,
the
positive
comments
about
the
current
design
of
all
Marr
that
emerged
in
the
interviews
first
going
open
source
is
great,
so
that
was
like
one
quote,
so
that's
a
positive
thing,
because
it's
forced
at
the
design
now
other
people
use
it,
that
the
quality
of
the
code
is
getting
higher
and
so
on.
B
B
B
Okay,
so
I'll
move
now
to
the
problems
with
the
current
design
and
I
kind
of
broke
them
and
sorted
them
according
to
how
many
people
talked
about
them,
so
they
go
from
most
common
to
least
common
kind
of
things.
So
the
first
main
problem
right
now
is
really
the
code,
navigation
and
comprehension,
and
this
comes
in
several
parts.
B
So
the
first
thing
is
as
a
newcomer,
it
is
actually
kind
of
hard
to
understand
what
what
oh
ma
rizz
exactly
and
how
do
I
get
started
with
it,
because
it's
not
a
standalone
product,
you're,
not
building,
something
that
you
can
run
right
away.
You're,
not
even
building
a
library
that
you're
going
to
either
statically
mclean
linked
in.
B
So
it's
hard
to
understand
like
where
do
you
get
started
with
it?
And
due
to
that
then
building?
It
is
not
always
straightforward
because
you
have
to
know
where
to
go
change
things
and
that
you
have
to
build
it
for
a
specific
architecture,
specific
language
and
after
you
even
add
those
extensions
and-
and
another
thing
is
the
extensibility
boundaries
are
not
that
well
defined.
B
So
in
some
cases,
so
even
the
fact
that
there's
now
two
ways
that
you
can
extend
Omar
so
there's
the
shipbuilder
route,
where
it's
more
of
an
API
on
top
of
Omar,
to
make
things
easier
to
extend
and
actually
is
somebody
kind
of
a
newcomer
to
Omar
that
wasn't
even
clear
to
me.
That
just
builder
is
a
it's
an
alternative
boot
to
go.
B
So
that's
one
option
you
have
and
then
the
other
option
is
to
directly
extend
the
extensible
classes,
similar
to
what
open
je9
does,
and
then
you
have
to
figure
out
that
there's
some
extension
points
that
have
default
implementations
from
don't
and
you
need
to
understand
where
you
want
to
extend
things.
So
the
newcomer.
This
is
really
hard
to
figure
out
all
of
those
things.
B
The
other
thing
in
terms
of
code
comprehension,
is
just
understanding.
What
does
a
given
class
look
like
on?
Let's
say
power
or
x86,
or
something
like
that,
so
you
need
to
understand
which
functions
are
defined
in
that
class
for
that
platform,
what
what
are
they
overriding
and
so
on
and
right
now,
it's
actually
hard
to
get
kind
of
a
static
picture
of
what
this
class
looks
like,
and
this
is
mainly
because
because
of
how
the
both
system
works
and
how
extensible
classes
it
is
actually
hard
to
navigate
the
code,
especially
in
an
ID.
B
What
I
understand
is
now
people
go
and
say,
let's
say,
I'm
working
on
Fedor
power,
I
go
get
all
the
include
paths
that
are
just
Forge,
that
empower
have
to
manually
go
plug
them
in
in
my
ID,
and
then
it
supports
it.
It's
not
easy
to
flip
back
and
forth
and
say:
okay
now
show
me
what
it
looks
like
on
x86
and
then
go
back
to
power,
and
things
like
that.
So
navigation
is
currently
one
of
the
issues.
B
There
is
also
the
fact
that
in
some
cases,
the
code
is
scattered
in
certain
parts
of
all
Mars.
If
you're
not
really
familiar
like
intimately
familiar
with
the
code
base,
it
might
be
confusing.
So
some
examples
is
like
managing
code
caches,
there's
two
classes
that
you
have
to
go.
Look
at
what
they're
both
doing
to
understand.
How
that's
done
query
is
where
you
look
at
whether
some
feature
is
supported
on
specific
platforms
or
an
hour.
B
B
And
then
related
to
that
is
also
the
idea
of
connectors.
I
I
can't
believe.
I
might
have
misunderstood
this
point.
If
somebody
wants
to
clarify
it,
I
believe
it's
mainly
using
the
TR
name
space,
but
is
what?
Because,
if
you
use
static
functions,
you
may
forget
to
actually
use
the
connectors
and
that
may
lead
to
wrong
behavior.
B
So,
if
you're
on
x86
and
you
forget
to
use
the
right,
connector
use
a
static
function,
you
might
end
up
getting
the
wrong
function
instead
of
getting
the
specialization
of,
like,
let's
say,
I
3,
8,
6
or
AMD
64,
so
yeah.
So
it
is
also
an
added
layer
of
complexity
and
it
may
be
error
prone.
If
you
don't
use
the
right
one.
B
So
putting
all
these
kind
of
together
and
also
from
feedback
I
thought
is
that
the
first
requirement
is
that
the
simplicity
and
usability
should
be
top
priority,
so
we
should
think
of
when
a
newcomer
comes
in
and
tries
to
use
this
code.
That
is
clear
where
extension
points
are
avoid.
Maybe
new
kind
of
constructs
like
self
and
connectors
that
are
not
that
intuitive
to
people
and
so
yeah.
B
The
second
problem
is
this
code
spread
that
happens
both
within
Almar
and
across
the
repositories
with
open,
j9
and
Almar,
so
because
of
this
hierarchy
and
the
fact
that
you
have
connectors
and
the
tRNAs
space
and
so
on.
If
you
make
a
significant
change
to
a
plus,
it
means
now
you
have
to
edit
several
files.
B
So,
for
example,
if
you
change
a
constructor
in
an
j9,
it
means
you
need
to
change
the
TR
version
as
well
in
all
Mar
or
that,
if
you
add
code,
that
is
j9
specific,
you
still
need
to
request
an
update
in
all
Mar,
and
actually
it
may
end
up
in
these
if
def
j9,
which
are
making
the
code
harder
to
read
and
making
maintenance
harder.
So
you
need
to
figure
out
that
you
need
to
not
only
edit
the
coast's
you're
interested
in
j9.
B
So
the
fact
that
it's
actually
the
code
is
spread
across
two
repositories
is
problematic
in
the
sense
that,
for
things
like
in
enums,
because
you
don't
know
what
the
downstream
project
depends
on
so,
if
you're
changing,
let's
say
enums
and
Almar,
you
need
to
be
very
careful
about
the
order,
because
open
g9
depends
on
a
specific
order
of
how
these
genomes
are
declared.
So
you
might
break
something
without
even
knowing,
because
it's
downstream
in
a
completely
different
repository.
B
What
I
understood
also
is
that
the
both
system
between
those
two
repositories
is
inconsistent.
Even
the
both
flags
to
indicate
architectures
are
not
the
same.
Things
like
cxx
flags
are
not
respected
and
open
j9.
So
it's
not
like
you
can
configure
your
boat
for
Omar
and
have
it
trickle
down
to
open
gen
I.
Have
all
these
build
options
trickled
down
and
again
because
of
the
fact
that
you
change
things
in
all
Mar
and
don't
know
about
the
dependencies
in
the
downstream
projects?
B
If
open
j9
has
any
assumptions
about
things
like
table
sizes
and
you
change
them
in
all
Mar,
you
may
cause
problems
that
will
not
even
end
up
and
break
it
raikage,
but
might
end
up
reading
incorrect
data,
for
example,
and
because
of
all
how
this
works
is.
It
ends
up
also
in
process
slowdowns
your
process,
additional
burdens
on
the
process
itself.
B
So
right
now,
if
you
need
to
make
a
change
in
open
j9,
it
often
means
that
you
need
to
touch
the
Oh
mark
code.
So
then
you
need
to
go
open
the
PR
and
Omar
and
wait
for
it
to
get
accepted
before
getting
on
with
your
work.
So
that's
kind
of
a
process
hurdle
there
and
also
the
fact
that,
because
of
this,
even
if
I'm,
not
an
core
of
our
developer,
I
may
end
up
needing
to
contribute
to
it.
B
So
it's
not
really
kind
of
a
good
separation
of
concerns
in
terms
of
developers
editing
so
based
on
this.
What
I
think
one
of
the
requirements
should
be
is
that
there
should
be
more
screen,
lined
consistency,
checks
and
editing
capabilities
where
I
can
edit
in
one
place
and
make
sure
that
it
trickles
down
to
all
the
right
places.
Now
how
this
is
done,
it's
still
open
for
discussion,
but
I
think
the
fact
that
you
have
to
go
edit
like
three
or
four
different
places,
if
it's
error-prone,
so
somehow
the
design
should
take
that
into
account.
B
So
the
extension
mechanism
right
now
is
basically
the
skirt
using
macros
and
includes
for
things
like
enums
and
that
you
need
to
go
back
to
Omar,
to
add
things.
So
the
example
here
in
the
slide-
I,
don't
know
if
I
can
get
my
mouse
know.
Okay
is
the
up
codes
where
first,
you
have
a
header
file
that
has
these
enumerations,
that's
included
in
the
and
they
enum
definition
and
the
order
that
these
enums
appear
need
to
be
the
same
order
that,
in
a
completely
different
file
that
has
the
properties
of
these
up
codes.
B
B
There
is
currently
no
way
that
you
can
just
add
an
extra
property
there
or
like
extend
the
enum
without
going
through.
This
include
magic
with
the
macros,
so
a
new
design
should
have
a
mechanism
for
extending
enums
and
unions,
and
when
talking
with
some
of
the
developers,
it
might
be
that
you
need
to
not
only
support
adding
new
fields,
but
also
maybe
changing
the
type
of
a
given
field.
So
you
might
in
your
your
Union
or
something
have
a
different
type
or
in
the
enum,
so
it
should.
B
It
should
be
able
to
support
the
both
adding
a
new
field
or
changing
the
type
of
the
field.
I
start
in
the
tables,
actually
changing
the
type
of
field
you
know
now.
The
fourth
problem
is
the
constructor
problem,
and
this
is
more
of
just
the
fact
that,
based
on
how
things
are
designed,
any
constructor
of
a
given
class
has
to
be
a
superset
of
all
the
other
architectures,
and
this
leads
to
extra
or
unneeded
parameters
for
some
architectures.
So
you
might
have
a
long,
constructor
long
parameter
list
for
the
constructor.
B
Well,
for
your
given
architecture,
you
don't
really
need
all
these
parameters
so
yeah,
so
that
causes
these
to
look
I,
guess
more
also
in
terms
of
just
code,
comprehension,
if
you're
an
architecture
that
doesn't
need
the
specific
problematic
so
as
a
requirement
how
we
want
to
be
able
to
have
some
bearing
constructors
across
the
architectures
or
languages
such
that.
You
only
need
to
specify
the
things
you
need
for
that,
given
architecture.
B
B
Change,
rather
than
a
design
change
per
se,
so
I
didn't
think
this
is
something
that
would
show
up
as
a
requirement,
but
we
can
discuss
this
at
the
end
as
well,
and
the
next
problem
is
all
Mars
legacy:
trackage,
basically
that
there
it's
too
much
chef
ism
inside
the
code,
the
intermediate
language
was
designed
for
Java.
So
a
lot
of
the
unmarked
code
is
actually
not
really
generic,
which
means
that,
as
new
things
start
to
be
needed
for
other
languages
and
other
Cline's
things
get
added
to
the
Omar
namespace.
B
And
then
it's
like
this
kitchen
sink
problem
where
you're
just
adding
things
without
thinking
about
what
is
the
generic
meaning
for
all
the
clients
or
how
can
this
be
more
general
and
extensible
so
as
a
fist
requirement,
the
new
design
must
be
based
on
language
independent
constructs.
Now
this
is
something
that
needs
internal
team
discussions.
It's
not
something!
That's
really
just
related
to
the
implementation
strategy,
because
these
gener
generic
functions
or
generic
extension
points
need
to
be
defined
for
to
be
language
independent.
B
So
that
was
the
problem
list,
but
and
kind
of
requirements
based
on
it.
But
during
the
discussions
there
were
also
additional
requirements
or
constraints
really
that
for
any
potential
solution,
so,
for
example,
on
right
now
all
the
variability
decisions,
so
you
know
like
at
compile
time
which
architecture
you're
building
for
which
language,
which
operating
system
everything
can
be
done
at
compile
time,
but
in
the
future.
B
B
Another
thing
is
that
when
InDesign
is
previously,
a
template
solution
was
was
explored
and
one
of
the
problems
with
that
is
that
it
resulted
in
strongly
connected
components
where
to
compile
one
class,
you
needed
to
pull
in
a
lot
of
other
components
that
are
tightly
connected
to
it
because
of
how
templates
work,
and
so
this
is
one
thing
that
you
want
to
avoid.
A
new
design.
B
Now
more
of
a
technical
constraint
is
that,
in
terms
of
C++
features,
we
cannot
use
something
that
is
not
supported
by
the
lowest
common
denominator
of
C++
versions.
Not
this
not
all
architectures
support
the
same
C++
version.
So
that's
something
that
needs
to
be
taken
into
account
not
to
use
advanced
language
features.
B
Another
requirement
is,
or
maybe
a
wish
list
is
kind
of,
maybe
to
enable
finer
control
over
extension
points.
So,
for
example,
you
might
want
to
say
that
this
function
is
only
exposed
to
all
mark
classes.
An
external
client
does
not
need
to
do
anything
with
this,
while
this
is
actually
an
extension
point
for
just
the
Java
client
for
the
Java
language.
B
This
so
I've,
let's
say
I've
extended
Omar
at
version
2
and
started
doing
things,
and
now
all
Maher
has
new
updates
and
I
need
to
incorporate
those
updates,
and
the
design
should
be
made
in
a
way
that
it
does
not
really
break
all
my
extensions
so
that
it's
easy
for
me
as
a
consumer
or
client
of
Omar
to
be
able
to
integrate
those
new
updates
and,
as
a
final
requirement,
is
to
keep
testability
in
mind.
So
the
design
should
enable
easier
testing
without
needing
to
mock
the
whole
compiler
to
test
any
single
parts
of
it.
B
So
this
is
my
last
slide
here
in
terms
of
thoughts
for
possible
solutions.
So
I
I
did
ask
everybody
my
cocktails
like
what
do
you
think
would
be
a
good
solution
or
a
better
design
than
what
you
have
and
I
mean?
Most
people
actually
didn't
really
know
what
a
better
design
would
be.
They
knew
what
what
is
causing
them
problems
or
pain,
but
not
really
how
to
make
it
a
lot
better.
B
There
were
some
ideas
like
having
more
of
a
cogeneration
framer
so
like
having
some
metadata,
where
you
could
describe
certain
things
and
then
have
the
code
generated
for
you,
based
on
what
architecture
you
want
and
so
on.
There
are
two
factors
here
that
need
to
be
taken
into
account
is
that
you
need
to
consider
or
be
able
to
also
debug
a
problem.
B
Many
of
the
same
I
guess
design
requirements
here
so
looking
at
them
to
see
how
maybe
they
handle
some
of
those
issues
could
be
used
as
a
source
of
inspiration
and
I'll
end
on
the
slide,
which
has
the
laundry
list
of
all
the
requirements
from
the
presentation,
and
we
could
use
it
to
start.
The
discussion.
A
Thanks,
sir
I
think
that
was
a
fairly
good
consolidation
of
of
your
discussions
that
you
had
with
with
the
developers
I
think
there's
a
lot
of
good
good
points
in
here
and
I.
Guess
one
thing
that
I
one
of
the
requirements
that
you'd
mentioned
late
was
the
the
need
for
or
the
potential
need
for,
adding
more
dynamicism
to
the
to
the
to
the
configuration
so
right
now,
you're
right.
A
We
do
assume
that
things
can
be
configured
statically
and
which
is
sort
of
wise
static
polymorphism
works,
but
as
we
are
starting
to
move
some
of
this
code
into
projects
in
the
cloud
which
may
need
more
dynamic
configuration
I
think
it
makes
sense
for
us
to
sort
of
factor
that
into
anything
that
we
are
thinking
about
now,
rather
than
added
on
as
an
afterthought.
So
you
know,
if
that's
the
way
that
we
want
to
go,
then
I
think
we
need
to
factor
in
dynamicism
this
such
a
work
again.
E
B
A
Well,
for
example,
our
t1
at
one
compiler
that
can
generate
code
for
multiple
backends
right,
so
I
want
to
be
able
to
cross,
compile
next
86
and
I
want
to
be
able
to
cross,
compile
the
power
on
the
same
compiler
right
now.
The
way
that
the
code
is
structured,
it
doesn't
really
work
that
way,
because
the
assumption
is
you're
going
to
have
one
code
generator
or
a
compiler.
B
A
F
A
G
C
G
G
So
the
Omar
codebase
used
to
be
shared
by
a
larger
number
of
compiler
projects
on
the
order
of
eight
different
compiler
projects.
Open
j9
was
one
of
which
one
of
those
and
was
the
original
one
that
the
code
base
was
developed
for,
but
there
been
avoided
on
the
order
of
a
decade
worth
of
development
to
create
those
other
compiler
projects.
G
G
Of
sort
of
very
weird
dependencies
tied
together
through
our
code
base,
that
was
hard
for
any
one
person
to
understand.
It
worked
very
well
for
each
individual
project
because
they
each
individually
understood
how
things
worked.
But
if
you
started
looking
at
the
different
projects,
it
became
hard
to
have
a
sort
of
unified.
G
We
use
the
term
conceptual
integrity
across
all
of
those
projects,
and
so
when
we
started
down
the
path
of
creating
Omar,
one
of
the
challenges
that
we
had
was
that
we
had
all
of
these
different
projects
and
not
all
of
them
wanted
to
be
open
sourced
along
with
Omar.
In
fact,
none
of
them
originally
wanted
to
be
open
source.
Even
j9
was
not
slated
to
be
open
sourced
originally,
and
so
we
had
to
find
a
way
to
marry
this.
G
This
open
source
form
our
generic
toolkit
ocean
with
you
know
multiple
different
consumers
using
the
classes
all
in
a
different
way
in
different
ways,
so
that
kind
of
led
to
so
the
I
guess.
It's
requirement.
Nine
right
enable
finer
control
for
extension,
points
which
originated
from
the
observation
that
the
current
extension
mechanism
lets.
You
override
just
about
anything
that
was
actually
by
design
at
the
time,
because
we
needed
the
ability
to
do
that.
Or
else
we
couldn't
have
any
notion
of
a
clean
or
more
implementation,
because
they
were
all
so
different.
So.
G
Well,
I
would
say
that
we're
on
a
we're
on
a
path
for
that
we
started
from
a
place
where
everything
was
Java,
centric
right.
So
in
the
end,
just
to
finish
my
earlier
story.
So
in
the
end,
we
we
ended
up
divorcing
from
not
the
right
term,
but
we
court
settlement.
We
we
separated
amicably
from
most
of
the
other
compiler
projects
and.
D
G
We
we
were
able
to
return
the
codebase
to
a
point
where
it
was
again
like
the
Java
JVM
JIT
that
we
started
from.
But,
as
you
know,
that's
the
very
Java
centric
kind
of
notion
is
so
we
then
had
to
proceed
on
the
refactoring
to
create
the
Omar
project
in
the
first
place
and
I
guess
one
of
the
pieces
that
that
we
didn't
make
as
much
progress
on
yet
as
we
would
have
liked,
is
the
making
the
Omar
project
a
little
bit
more
generic
than
then
it
currently
is.
G
A
A
B
Yeah,
so
I
think
this
would
go
back
to
this,
so
I
take
those
as
kind
of
the
basic
design
requirements
that
the
compile
time
performance
and
the
memory
footprint
and
runtime
performance.
So
those
and
I
believe
this
is
also
what
drove
the
current
design
like
with
the
static
polymorphism.
Is
things
like
the
runtime
performance
was
something
people
were
worried
about
so
yeah?
So
definitely
that
would
be
something
that's
taken
into
account.
I.
A
Guess
that
just
given
some
of
the
requirements
that
that
have
been
raised,
I
think
one
of
the
things
that
may
be
a
limiting
factor
as
well
is
not
just
the
C++
compiler
version,
but
just
the
capabilities
of
C++
and
it's
preprocessor
for
solving
some
of
these
problems,
which
I
think
might
be
why
some
have
suggested
a
more
metadata
approach
to
this.
In
that
you
can't
we,
you
may
not
be
able
to
get
C++
to
solve
all
these
problems
on
its
own.
It
may
need
some
other
tooling
help
in
order
to
achieve
that.
B
H
Say
three
is
pretty
important:
two
is
three
I
believe
in
you
know
that
is,
unless
I
put
in
my
side
right
now
with
äôt,
it's
kind
of
annoying
to
have
to
go
to
all
bar
to
love
tape,
the
real
kind
only
to
use
it
in
j9,
it
sort
of
be
nice.
We
could
have
an
extension
point
there,
so
that
the
things
that
only
canine
cares
about
can
be
in
j9,
I.
Think.
G
B
A
There
are
j9,
there
are
open,
j9,
specific
optimizations
and
they
are
added
to
that.
Optimization
ena
and
the
initialization
code
is
factored
in
such
a
way
that
if
you
have
a
open,
j9
specific
opt,
it
only
has
to
be
initialized
in
open
j9.
The
only
reason
that
there's
still
lots
of
pollution
in
to
omars,
but
the
options
processing
doesn't
handle
that
Eckerd
instability
properly.
Yet
the.
G
D
B
B
D
H
G
Auto-Generated
I
think
I
mean
certainly
the
problem
with
the
äôt
is
the
structure.
Is
that
there's
a
bunch
of
it
just
has
to
live
in
a
ot,
because
the
code
generators
live
in
a
ot.
That's
the
code,
that's
generating
the
relocation,
so
there's
a
kind
of
a
connectedness
problem
here
that
you
want
the
code,
generators
be
in
or
more,
it
would
mean
you've
done
something
or
Darrell's
done.
Some
work
to
try
to
genera
size.
The
notion
of
adding
a
relocation
to
in
when
the
co
generators
operating
believe.
G
But
the
fundamental
problem
is
the
relocation
infrastructure
needs
to
live
in
Omar,
so
what
the
code
generator
can
use
it.
But
then
the
implementation
of
the
relocations
is
all
Java
specific,
so
it
lives
in
open
j9,
which
probably
we
don't
want
to
sync-
the
Java
implementations
into
Omar.
That's
not
the
right
solution,
but
now
the
problem
is
that
there
is
a
bunch
of
Java
stuff.
Still
you
have.
B
G
G
More
that
we
can
fix
that
problem,
I
think
that
if
there's
one
requirement
on
the
list,
that
I
would
be
prioritize.
In
my
opinion,
which,
for
whatever
that's
worth,
would
probably
be
requirement
6
because
I
don't
the
kitchen
is
a
service.
People
may
differ
on
this
point
with
me
because
they're
the
ones
who
are
likely
to
struggle
with
this
one,
but
my
my
general
opinions
that
we
should
just
build
a
different
compiler
and
then
have
a
meta
process
managing
that
problem.
G
At
least
we
consciously
made
that
decision
called
it
kicking
it
down
the
kicking
the
can
down
the
road.
We
consciously
made
the
decision
at
one
point
that
certain
things
were
going
to
be
static
and
I.
Think
that
decision
back
then
probably
has
made
it
harder
to
go
back
and
make
those
things
dynamic,
but
I'm
not
sure
I
see
a
justification
for
making
them
dynamic
in
a
single
implementation
of
the
compiler
right
now
so
requirement.
H
G
D
G
G
A
Yeah
no
I
know
a
lot
of
people
will
be
pointing
at
LLVM
and
reuse
of
C++
in
LLVM.
However,
if
you
have
ever
had
the
joy
of
trying
to
get
that
project
to
build,
especially
with
you
see,
you
have
not
experienced
the
level
of
pain
equivalent
to
that
because,
like
the
for
the
what
they
they
maintain
lists
of
known
good
GCC
versions,
there
are
many
versions
that
don't
build
the
code
base
and
they
regularly
factor
in
you.
A
C++
language
features,
but
the
implementations
of
those
are
not
generally
consistent
at
the
point
where
they
start
appearing
in
the
code
base,
and
it
causes
a
lot
of
pain
for
some
people.
Also,
they
do
do
a
lot
of
the
metadata
table
generation
kind
of
stuff.
They
even
have
table
gen,
which
is
a
Python
script.
That
does
this.
A
It
has
its
laid
properties,
however,
if
you
ever
actually
have
to
go
and
modify
some
stuff
with
table.
Jen
you'll
rapidly
discover
that
it
is
a
DSL
full
of
single
letter
abbreviations
for
things
and
where
lowercase,
L
and
capital
L
mean
different
things
and
you
have
to
go
and
back
solve
exactly
what
this
set
of
ISA
Taric
flags
actually
means.
So,
while
you
don't
have
to
have
coupled
implementations,
you
have
a
sufficiently
terse
an
abbreviated
form
that
was
convenient
for
the
person
who
wrote
it,
but
it
is
not
easy
to
figure
out
after
the
fact.
A
G
A
I
mean
the
x86
code.
Generator
is
built
using
that
now
right.
There's
one
macro
expansions
into
particular
lists,
define
everything
in
one
row
and
then
pick
the
parts
that
you
want
for
each
of
the
different
things
so
that
it
can
generate
the
names
and
the
route
enum
and
the
properties,
and
that
your.
I
B
B
G
C
I
C
B
B
A
C
A
C
G
Are
ways
that
there
are
ways
of
making
it
cleaner
like
easier
to
use
yeah
I
could
do
the
like.
You
pass
the
object
alone,
so
you
you
write
a
setter
on
the
struct
for
every
field
and
then
everybody
just
does
like
create
one
of
these
things
and
then
dot
set.
This
thing
to
this.
Does
that
same
thing?
To
that?
G
Don't
set
that
think
of
a
thing
you
construct
or
you
can
do
it
the
other
way
around
you
can
you
can
separate
construction
from
initialization
if
you
really
do
gene,
but
this
is
just
one
thing
where
the
C++
notation
just
doesn't
quite
work
there.
No,
there
are
no
clean
solutions
to
it.
Unfortunately,
if
you're
really
trying
to
do
mix
in
which
in
a
bunch
of
places,
we
are.
B
And
then
it
in
terms
of
requirement
to
which
was
related
to
this
idea
of
that
you
have
things
in
all
more
there's,
an
j9
that
are
tightly
coupled,
Zalm
are,
and
that
might
lead
to
inconsistent.
These
are
the
pain
of
going
and
editing
two
places
and
what
I
understand
from
the
discussion
we
have,
but
a
few
minutes
ago,
it's
mainly
if
the
design
can
avoid
the
tight
coupling,
in
the
first
hand,
to
avoid
this
problem.
G
A
lot
of
things
I
think
that
we
have
to
fix
in
order
to
get
to
completely
eliminating
the
coupling
between
omar
and
open
j9
would
be
a
lot
a
lot,
a
lot
of
work,
just
why
it
hasn't
been
done.
Yet
we
can
where
we
are
moving
gradually
towards
it,
but
gradually
is
probably
the
most
appropriate
word
in
that.
B
H
H
H
H
G
H
D
G
D
G
Right
now
it's
very
open-ended.
We
now
have,
if
you'll
forgive
the
word
in
this
use.
We
have
the
luxury
of
of
applying
requirement
9,
which
we
didn't
in
the
past.
In
fact,
we
had
to
go
the
other
direction
because
of
the
design
point
that
we
were
forced
into
at
that
time
now,
I
think
we
have
that
luxury
and
I
think
we
should
exploit
it
because,
as
you
say,
I
think
it
simplifies
consume.
G
How
consumers
of
the
project
will
understand
how,
but
they
need
to
do
in
order
to
modify
the
compiler
and
modify
it
in
ways
that
we
can
anticipate,
which
means
it
easier
for
us
to
devise
testing
around
not
that
we've
done
a
great
job
with
this.
But
if
we
know
where
the
extension
points
are
it's
easier
for
us
to
understand
how
testing
should
be
done
at
the
Omar
project
layer?
If
you
can
change
anything,
then
how
do
you
test
that.
B
But
this
is
not
about
also
changing
okay,
so
there's
two
things
here:
one
is
make
the
extension
points
clear.
That's
definitely
something
that
needs
to
be
defined
because
otherwise
people
don't
know
what
to
extend.
The
testing
is
hard,
but
there's
also
whether
you
want
a
granularity
control
to
say
that
this
is
an
extension
point
for
only
within
all
Maher,
and
this
is
for
any
consumer.
This
is
only
for
the
j9
once
I,
don't
know
if
that's
something
required
or
that
that
you
can
see
use
cases
for
or
if
it's
just.
This
is
extra
stuff.
G
Are
so
you're
suggesting
that
maybe
there
are
places
where
we
want
to
be
able
to
enable
extension?
We
call
it
extension,
but
whatever
it
over
writing
of
behavior
across
architectures
within
the
Omar
project.
But
we
don't
want
language
projects
above
or
more
to
be
able
to
leverage
those
same
extension
points
because.
B
E
B
So
in
terms
of
logically,
are
there
things
that
you
don't
want
to
that?
You
want
to
open
up
for
anybody,
or
only
say
this
is
consumer.
This
is
internal
or
even
if
you
want,
but
but
then,
if
you
mark
here
for
specific
consumers,
I
think
that
makes
it
no
longer
language.
Agnostic
or,
like
you
mean
you
need
to
know
which
ones
then
you're
making
a
lot
of
customizations.
Maybe
that's
not
a
good
thing,
so.
D
Just
a
clarification,
I
think
also,
let's
say
in
the
future:
we
we
define
an
API
form.
Our
compiler
I
think
the
requirement
here
is
saying:
maybe
some
API
now
I
only
want
to
make
available
one
customer
versus
the
other
this
this
a
requirement
that
we
foresee
will
be
useful
near
to
me
in
future,
coordinate
new
stuff.
G
Like
that,
because
you
just
devise
different
classes
right
so
you'd
have
one
classes
for
being
extended
up
the
up
the
chain
and
the
implementation
would
be
envisioning.
It's
kind
of
like
the
change
we
just
made
to
build
in
a
way
right
to
hide.
I
could
kind
of
had
that
concern
into
filter
too,
but
there's
a
bunch
of
public
API
in
the
implementation
classes
that
we
didn't
want
clients
to
use
and.
I
G
G
No
I
get
it
I'm.
Just
my
suggestion
would
be
that
we
just
have
certain
classes
that
are
private,
not
extensible,
and
that's
where
we
not
extensible
outside
of
form
or
in
some
way
it
would
be
better
to
say,
like
they
may
have
a
public
API,
but
you
tell
people
these
classes
they're
not
to
be
used
outside
of
Moammar.
The
extension
point
as
this
class
over
here,
which
is
up
I,
know
you
can't
protect
it
with
C++,
but.
H
G
I
know
this
so
the
original
extension
mechanism,
I
guess,
was
designed
for
the
to
be
for
extension
by
language,
and
then
we
later
added
architecture
into
it,
because
it
kind
of
folded
into
this
seemed
like
it
was
solving
the
same
kinds
of
problems
and
so
using
the
same
mechanism
to
deal
with
architecture,
specialization
and
language
specialization
seems
like
a
reasonable
fit,
but
I
just
we
don't
have
to
do
it.
That
way,
right
like
we
could
in
principle
anyway,
retreat
to
a
you
only
extend
by
language,
and
we
do
architecture
specialization
differently
right
like
originally.
G
G
G
If
you
have
the
name
of
the
thing,
you
would
just
have
a
no
mark,
:
:,
x86,
:,
:
code
generator,
which
would
extend
Omar
:
:
code
generator,
and
then
it
would
be
propagated
up
through
the
language
and
if
it
would
just
be
extensible
by
itself,
you
would
you
you
would
expose,
but
Omar
and
x86
code
generator
as
a
valid
class
for
being
extended.
But.
G
G
Another
way
you
might
be
able
to
order
that
again,
I,
don't
know
if
that
it's
possible
or
not
have
to
think
through
this
a
bit
more
because
I
know
we
settled
on
the
solution
for
a
reason,
but
another
way
to
do
that
would
be.
You
have
common
common,
common
and
in
architecture,
architecture,
architecture
and
they
extend
at
that
level.
I'm
not
explaining
this
very
well.
G
G
B
Okay,
so
so,
if
I
try
to
summarize
this
for
requirement
nine,
it
seems
that
the
clarity
for
requirement
nine
is
making
the
API
clear
as
a
consumer.
What
are
my
extension
points?
The
fact
that
I
want
it
like
specify
that
I'm
exposing
this
only
to
consumer
X,
that's
maybe
an
extra
thing,
but
not
like
a
heart
requirement.
G
G
One
user
would
communicate
with
one
of
the
compilers
and
the
other
user
would
communicate
with
the
other
one,
managing
that
the
dynamism
between
having
a
single
process
that
can
act
as
one
or
the
other
I
think.
That's
actually
more
complexity
than
it's
worth
right.
I
would
rather
have
a
compiler
that's
designated
for
compiling
Java
code,
one
that's
designated
for
compiling
Ruby
code.
G
You
know
on
x86
and
if
a
different
one
of
you
want
it
for
power
for
whatever
or
arm
or
whatever
I
think
the
complexity
of
having
a
compiler
that
could
generate
both
Java
x86
and
Java
on
arm
I,
don't
I'm,
not
sure,
that's
worth
it.
I
aren't
the
complexity
of
enabling
that
in
the
code
base,
so
that,
given
you
know,
and
on
top
of
that,
there's
the
sort
of
feasibility
like
the
issue
that
there'd
be
a
lot
of
work
to
make
that
happen
right,
oh
and.
B
B
C
A
If
you
have
the
right,
if
deaths
in
your
IDE
environment,
it
does
work,
but
you
do
get
to
see
the
enum
and
everything
because
the
IDE
preprocessor
is
able
to
see
the
expansion
right,
whereas
if
you
have
an
opaque
Python
script,
for
example
that
require
some
bespoke
process
to
run
it,
then
that's
less
transparent
right
now,
maybe
you
can
run
it
and
generate
a
file,
and
then
you
can
include
that
file
and
you
only
have
to
regenerate
it
under
certain
circumstances
involve
a
lot.
But
then
you
know
you
still
have
that.
B
Sure,
because,
because
the
other
thing
that
I
mean
speaking
of
if
and
what
is
currently
there,
there
could
be
a
completely
different
route
of
just
support
tools
for
different
kinds
of
Cinci
checks
and
trying
to
avoid
some
of
the
problems
that
have
been
discussed.
Some
of
them
cannot
like
things
like
the
varying
constructors
and
so
on.
That's
nothing.
The
tool
will
help
with
and
you
could
have.
If
that's
there
too,
what
that
will
looks
really
ugly,
but
that
could
be
one
way
is
just
like
to
support
on
top
of.
B
A
Yep
no
I
agree.
It's
very
complex
space
to
try
and
work
in
I
think
it
was
just.
The
point
was
being
raised
on
the
cat,
so
I
did
want
to
just
wanted
to
mention
it,
but
I
certainly
agree
that
tooling
off
to
the
side
to
facilitate
checks-
and
things
like
that
is
is
very
helpful.
I
mean
people
complain
about
the
self
and
the
current
linter,
but
it
is
actually
preventing
problems
if
certain
things
are
extended.
If
you
don't
have
those
selves,
it
just
won't
work
right.