►
From YouTube: Eclipse OMR JitBuilder Status and Focus 2018
Description
This presentation at the 20180328 OMR Compiler Architecture Meeting is an update on the current status of the JitBuilder library in the Eclipse OMR project and outlines focus areas for advancement of the technology in 2018.
A
Okay,
so
for
this
week's
topic,
we
have
mark
stably
here
to
talk
about
the
the
sort
of
current
status
of
the
the
JIT
builder
technology.
That's
that
exists
in
Omar
and
what
what
we
plan
on
doing
with
it
over
the
next
over
the
next
few
months-
and
we
certainly
want
to
you-
know,
hear
everyone's
anyone's
opinion
that
they
have
on
and
on
it
and
in
areas
that
we
that
they
think
we
should
go
with
it
and
how
they
can
contribute
in
that
sort
of
thing.
So
so
I'll
start
bumbling.
B
It
away
hi
Sarah,
so
I'm,
mark
studly,
I'm,
Project
Lead
for
Eclipse
Palmer
and
also
for
open,
j9
and
I
have
the
honor
to
be
the
creator
of
b2
builder
library,
which
I
guess
uniquely
positions
me
to
be
a
person
talking
about
what
the
current
status
of
the
project
is
and
where
we're
trying
to
take
it.
People
often
ask
me
what
all
is
happening
with
kit
builder
and
they
often
the
answer
only
exists
in
my
head.
So
that's
a
form
of
excellence.
B
That's
actually
a
kind
of
failure,
so
I
accepted
this
invitation
to
talk
here
as
a
way
to
pressure
myself
to
write
more
of
these
things
down
and
to
create
issues
at
the
at
the
repository
where
people
can
give
us
feedback
and
can
participate
in
the
creation
of
this
plan
in
the
evolution
of
this
plan.
So
this
presentation
is
really
a
starting
point.
C
B
So
in
terms
of
an
agenda
as
kind
of
three
basic
areas,
I'm
just
going
to
give
a
quick
introduction
to
they
did
build
their
library
for
anybody
who
doesn't
know
what
it
is
but
happen
to
be.
Listening
to
this
presentation
and
give
a
little
bit
of
status
on
some
of
the
current
projects
that
are
using
to
builder
I'll
then
switch
over
into
the
focus
areas
for
three
different
types
of
work.
B
That's
going
on
at
the
project
right
now
and
that
I'm
hoping
will
complete
within
sort
of
timeframe
of
the
2018
calendar
year
and
I'll
wrap
up
at
the
end
with
hopefully
some
easy
ways
for
people
to
get
involved.
If
they're
interested
after
I've,
hopefully
motivated
you
to
be
excited
about
this
project.
C
B
Api
wrapping
around
the
Omar
compiler
component
and
the
emphasis
in
designing
that
ap
API
was
really
around
ease
of
use
and
trying
to
avoid
some
of
the
complexities
and
subtleties
of
the
underlying
technology
used
to
compile
code.
It's
also
designed
for
use
by
programs
to
generate
native
codes.
So
it's
not
written
along
the
lines
of
trying
to
make
it
super
easy
for
humans
to
understand
and
to
generate
it's
not
meant
as
an
alternative
to
a
programming
language,
because
it's
a
lot
more
verbose
than
that.
B
But
it's
meant
to
be
easy
to
write
a
program
to
use
the
API
to
generate
native
code,
and
that
means
it's
really
created
for
writing
just-in-time
compilers,
but
it
can
be
used
really
to
accelerate
just
about
anything
that
any
kind
of
operations
that
you
you
want
to
generate
native
code
for
at
runtime.
The
library
itself
is
already
quite
useful,
there's
quite
a
lot
of
things
that
it
can
do,
but
there's
actually
quite
a
lot
more,
that
it
could
do
it's
currently
a
library
that's
implemented
in
C++.
B
So
it
best
supports
people
who
want
to
write
C++
code
and
it
supports
a
wide
variety
of
primitive
data,
types,
arithmetic
control,
flow
operations,
etc.
So
this
page
is
not
something
I'm
going
to
go
through
in
detail.
It's
really
just
a
little
compendium
of
all
the
different
things
that
you
can
currently
do
with
JIT
builder,
and
so
it's
a
fairly
rich
set
of
operations
that
you
can
do
in
rich
types.
You
can
work
but
as
I
say,
there's
always
more
that
we
can
do
and
things
that
are
missing.
B
Are
the
student
Leonardo
created
the
lieu
of
vermelha
JIT
and
we've
been
making
improvements
in
it
to
to
improve
performance
and
keep
moving?
Now
and
forward
the
rosy
pattern.
Language
is
another
example,
just-in-time,
compiler
that
we
wrote
using
the
JIT
builder
library,
with
about
1,200
lines
of
C++
code
and
I'm
not
going
to
go
through
all
these
in
detail.
But
you
know
there's
a
JIT
for
Swift,
which
is
about
one
third
of
a
budget
for
Swift.
There's
a
small
talk.
Runtime,
that's
been
decided,
get
created
for
it
at
the
Omar
project.
B
There's
a
there's
a
run
time
called
base
nine
that
we're
using
to
develop
a
tutorial
around
how
to
use
the
Omar
or
project
and
the
Omar
components,
a
very
cool
one.
That
I
just
watched.
The
final
project
report
for
actually
just
before
this
meeting
is
a
web-based
webassembly
JIT
that
was
created
using
at
the
University
of
Calgary,
using
JIT
builder
and
in
the
course
of
a
one
year
project,
most
of
which
was
in
the
second
term,
they've
implemented.
B
Basically
80%
of
the
web
assembly
opcode
set
using
about
2,000
lines
of
code
and
that's
speeding
up
web
assembly
programs
by
you
know.
Factors
of
Mandelbrot,
for
example,
was
14x
faster
and
there's
still
a
lot.
We
can
do
with
that
to
to
make
it
even
better,
but
as
an
undergraduate
project
that
says
that's
a
pretty
cool
accomplishments
to
start
from
zero.
B
We
have
t4,
which
is
a
JavaScript
implementation,
and
also
this
kaleidoscope,
ship,
which
was
meant
as
a
sort
of
comparison
point
against
the
LLVM
to
trail
I,
included
links
here
for
all
of
these
project.
In
case
you
want
to
learn
more,
but
one
of
the
things
I
just
wanted
to
highlight
was
the
amount
of
code
that
people
had
to
write
to
use
jet
builder.
B
So
maybe
the
the
the
performance
that
you
can
see
from
in
these
in
these
such
compilers
may
not
match
the
100x
numbers
that
you
hear
with
other
projects,
but
it
also
comes
with
a
much
lower
investment
level
and
we're
always
improving
Omar
and
it
builder
to
try
to
improve
the
performance
and
we're
hopeful
that
we
can
get
there
without
requiring
a
massive
amount
of
investment
in
terms
of
agent
builder
clients.
So
there's
nothing
here,
that's
more
than
three
thousand
lines
of
code
in
any
of
these
projects.
B
Right
now,
alright,
so
that's
just
a
quick
summary
of
just
builder
and
and
where
we
are
today.
The
real
question
here
is:
what's
what's
what's
coming?
Next,
what's
coming
down
the
pipe,
so
there
are
really
three
focus
areas
in
my
mind:
Forge
it
builder
in
the
2018
year.
The
first
one
is
really
to
broaden
the
scope
of
access
to
the
gist
builder
library,
so
that
you
can
use
that
it
has
a
native
acceleration
library
for
for
multiple
languages,
not
just
C++,
whereas
you
saw
most
of
the
current
projects
are,
are
based.
B
A
second
area
of
focus
is
around
integrating
the
builder
API
with
some
work.
That's
been
happening
at
the
Eclipse
Omar,
sorry
at
the
Eclipse
open,
j9
project
that
will
be
open
source
there
in
the
next
couple
of
months,
around
JIT
as
a
service
and
I'll
talk
more
a
little
about
what
that
means
and
how
JIT
builder
fits
in.
And
finally,
there
are
a
number
of
functional
gaps
that
have
been
identified,
both
in
the
Omar
compiler
component
and
other
components,
as
well
as
in
the
JIT
builder,
API
and
implementation
itself.
B
Okay.
So
let's
go
through
these
three
things
in
in
order
I'm
going
to
spend
the
bulk
of
my
time
on
the
first
one,
which
is
the
multi
language
native
acceleration
library.
So,
as
I
mentioned,
jiff
builder
is
currently
mostly
most
easily
used
by
C++
projects,
because
it's
essentially
a
wrapper
around
the
Eclipse
Omar
compiler
components
which
are
C++
classes.
B
It
is
possible
to
hide
a
compiler
implementation
using
chip
builder
behind
a
C
interface,
but
the
bulk
of
the
code
still
needs
to
be
C++
because
they
need
to
access
those
C++
classes
that
provide
most
of
the
services.
So
basically
that
means
to
use
G
builder,
you're
kind
of
locked
in
to
C++
right
now,
but
news
flash,
not
everyone,
likes,
writing
C++
code
I
know
it's
amazing
to
think
that.
B
So
the
first
primary
goal
for
building
or
2018
is
to
sustainably
and
I'll
talk
a
little
bit
more
about
what
I
mean
by
sustainable
in
this
context
enable
different
language
bindings
for
the
jib
builder
API
and
there's
a
series
of
things
that
I've
been
working
on
over
the
last
couple
of
months,
piece
by
piece
trying
to
put
together
this
story.
The
first
piece
is
trying
to
separate
the
client
builder
API
from
the
public
implementation.
That's
currently
in
the
Omar
classes.
B
Now,
because
the
JIT
builder
classes
are
all
maher
classes
and
those
classes
need
to
talk
to
one
another
as
well
as
expose
a
public
API
out
to
build
our
clients.
The
API
is
kind
of
all
mixed
together,
and
so
the
first
step
is
to
really
isolate
what
the
client
to
build.
The
API
is
from
from
the
implementation.
B
B
If
you
have
n
language
bindings,
then
it
starts
becoming
an
order
and
amount
of
work
in
order
to
add
new
api
digit
builder
and
eventually
that
work
will
just
basically
stall
due
to
the
cost
of
doing
it.
So
the
idea
is
to
introduce
this
data
format
from
which
you
can
then
create
other
bindings
automatically,
so
that
the
work
to
augment
or
to
work
with
the
JIT
builder
api
is
is
basically
kept
a
via
sort
of
order.
B
So
this
you
know
goes
back
to
as
part
of
the
mission
statements
that
they
put
some
our
project
itself,
which
is
to
we'll
be
able
to
leverage
investments
in
runtime
technologies
across
a
number
of
different
language,
ecosystems
and
I.
Think
this
would
be
a
really
great
way
to
be
able
to
get
people
using
JIT
builder,
Anika,
solar,
and
you
know
everybody
basically
helping
to
lift
everybody
else's
folks.
B
At
the
same
time,
so
just
to
put
a
little
bit
of
sort
of
a
visual
spin
on
that
I
put
some
slides
together
and
I
apologize
for
the
roughness
of
the
of
the
drawing
my
my
cursory
management
in
PowerPoint.
Isn't
so
good,
but
but
bear
with
me
so
at
the
bottom
of
this
diagram
we
have
the
eclipses
home.
Our
compiler
component
writes
one
of
the
technology
components
in
the
eclipse
of
our
project.
B
On
top
of
out
of
this,
the
current
set
of
builder
implementation
classes,
plus
this
API
description
that
I
talked
about,
which
essentially
has
a
bunch
of
data
that
describes
what
API
is
needed
in
order
to
access
the
JIT
builder
implementation
and
then
on
the
left
side.
Over
here
we
have
an
auto-generated
C++
for
now
builder
API.
B
So
this
is
a
client
API
that
can
be
accessed
and
linked
into
a
C++
library,
which
can
then
be
used
by
any
kind
of
C++
program
to
generate
to
generate
native
code,
and
so
this
this
diagram
basically
shows
the
C++
shipbuilder
library
akin
to
what
exists
today.
But
slightly
these
two
parts
right
now
are
the
same
classes
in
in
Eclipse
Omar.
B
Compiler,
the
idea
of
breaking
out
the
client
API
essentially
creates
the
separate
piece
from
here,
but
it's
being
automatically
generated
from
this
API
description
and
the
advantage
of
doing
that
is
that
you
could
also
do
it
for
another
language.
So,
in
this
slide,
I
showed
a
sea
library.
So
a
sea-based
jet
builder
API.
Now
this
won't
be
exactly
the
same
API,
because
you
can't
do
everything
with
C
that
you
can
do
with
C++.
B
For
example,
you
don't
have
classes
that
work,
quite
as
naturally
in
NC
as
you
do
in
C++,
you
don't
have
namespaces,
etc,
but
you
could
use
a
generator
program.
Written
from
this,
API
can
generate
essentially
the
same
services
via
a
C
API
as
you're,
currently
getting
from
a
C++
API,
and
then
that
API
can
be
built
into
a
C
library
which
can
then
be
linked
into
any
C
program.
And
now
you
can
write
a
C
program
that
can
generate
native
code.
You
a
JIT
builder
like
API,
and
you
can
keep
going.
B
You
can
build
more
languages
in
here,
so
another
language
that
we've
heard
some
demand
for
is
the
java
programming
language
probably
heard
of
it,
and
so
here
you
can
use
another
generator
to
write
a
Java,
JIT
builder
API
from
this
API
description
and
then
link
that
all
together
in
a
Java
library
which
can
be
consumed
by
a
Java
program
to
generate
native
code.
And
here
you
have
a
couple
of
options,
because
the
JVM
itself
has
a
has
a
JIT
compiler.
B
So
maybe
you
manage
an
independent
native
code,
cache
which
I
showed
a
prototype
for
that
at
JB
MLS
a
couple
of
years
ago,
or
if
you
have
the
ability
to
integrate
this
this
library
into
the
JVM
itself,
you
might
even
be
able
to
consider
generating
native
code
into
the
actual
JIT
compilers
code,
cache
within
the
JVM.
So
there's
some
interesting
options,
specifically
in
the
Java
ecosystem.
C
B
Okay.
So
so
that's
the
grand
vision.
Sadly,
there's
going
to
be
some
breakage
from
people
who
are
using
jet
builder
right
now,
which
I
know
is
sad
but
I
think
it's
necessary
in
order
for
us
to
move
forward.
The
first
point
is,
you
know:
just
builder
classes
are
in
fact
Omar
compiler
classes,
so
they
have
names
like
tiara,
:,
:,
builder,
tiara,
:,
:
method,
builder,
etc.
B
B
Alright,
not
surprising
I
guess
so,
the
the
second
form
of
breakage,
which
isn't
actually
a
mandatory
thing
to
do
right
now,
but
it's
a
it's
kind
of
an
opportunity.
I
guess
to
clean
up
the
the
current
should
builder
API
so
right
now,
because
because
the
implementation
and
the
client
code
is
all
mixed
together
in
one
class
and
there's
kind
of
these
two
different
types
of
or
two
different
notions
of
public.
B
C
A
B
C
B
A
C++
programmer
I
guess
I've
always
been
vaguely
offended
by
the
notion
of
having
a
capital
A
at
the
beginning
of
my
function,
names
that
I
had
to
call,
and
so
one
thing
that
I've
proposed
is
that
we
could
maybe
change
these
back
to
lower
case
and
I.
Think
that
reads
a
lot
better
to
me
to
see
those
the
names
like
that.
So
there's
there's
also
discussion
going
on
on
this
particular
point
inside
2397.
If
you
have
opinions
here
on
on
where
that
should
go,
you
know
please
feel
free
to
to
to
join
us
there.
B
Another
interesting
opportunity
that
we
get
now
to
once
the
client
API
has
been
separated
out.
We
can
now
version
that
API
using
semantic
versioning
to
represent
what's
going
on
with
the
API
and
when
breaking
changes
are
being
introduced
into
it.
So
there's
an
issue
1819
where
I
work
with
that
I
think
that's
a
doesn't
need
to
introduce
the
point
and
then
finally
I
guess
the
the
last
point
that
I
wanted
to
bring
up
here.
B
C
B
B
So
I
just
wanted
to
give
up
reef
sort
of
notion
of
what
the
API
description
currently
looks
like
I.
Have
some
change
sets
sitting
in
my
laptop
that
I
will
be
pushing
out
shortly
just
to
give
people
a
flavor
for
what
this
looks.
Like
I
tried
very
hard
not
to
make
this
look
like
ugly
C++,
but
it
is
still
C++.
So
I
did
my
best.
B
One
other
option
here
is
to
move
to
a
to
a
true
data
format
to
represent
these
things,
but
for
now,
I've
just
represented
them
as
they're
actually
stored
in
C++
arrays
that
are
put
together
using
various
helper
macros
like
this
class
fields
and
so
on.
So
the
idea
is
that
you
can
in
this
particular
example.
This
is
what
the
isle
builder
class
looks
like,
so
you
can
specify
some
documentation
for
the
class.
What
its
name
is-
and
you
know
flags
if
it
has
a
superclass
etc.
B
If
it
has
a
set
of
fields,
you
can
list
those
fields
here.
So
engine
engine
builder,
to
make
it
easy
for
people
to
reference
the
primitive
types
they're
all
cached
inside
every
I'll
builder
object
from
the
type
dictionary.
So
that's
what
these
fields
represent
are
the
primitive
types
that
you
can
use
anytime
within
a
jet
builder
object.
B
B
What
what
are
these
language
bindings
look
like,
so
this
is
kind
of
a
part
of
the
C
binding
that
I've
got
so
far.
So
it's
you
know:
creating
a
header
file,
opening
it
up
the
prologue,
just
issues,
a
copyright,
header
and
so
forth.
You
can
ask
for
an
include
file,
because
it's
a
data
format
that
has
all
the
classes.
B
You
can
ask
the
API
to
iterate
through
the
classes
using
a
fairly
familiar
looking
mechanism
to
to
iterate
through
and
then
this
block
of
code,
for
example,
is
just
issuing
a
type
def
statement
for
each
of
the
classes
in
the
in
the
in
the
API.
And
then,
if
the
class
has
a
superclass,
you
can
include
its
it's
named
header
file.
This
is
a
C
binding,
so
it's
a
dot,
H,
etc.
B
So
that
you
know
the
idea
is
to
build
up
a
set
of
services
inside
these
binding
files
so
that
it's
relatively
easy
to
just
spit
stuff
out
into
into
a
header
file.
And
then
you
know
the
idea
is
for
the
Jin,
even
the
generated
code,
to
be
fairly
easy
to
read,
but
also
fairly
easy
to
walk
over
the
the
language.
Sorry
that
just
builder
API
definitions
and
do
whatever
you
need
to
do
with
them,
and
so
that's
not
a
full
explanation
and
I
haven't
actually
pushed
the
commit
to
my
to
my
repo.
B
B
Guess
two
places
you
have
to
add
an
implementation
in
the
actual
implementation
layer,
and
then
you
have
to
add
that
the
description
of
the
API
you've
added
and
update
the
semantic
versioning
appropriately
and
then
just
rerun
the
generators
and
you
get
all
the
existing
language
bindings
regenerated
with
your
new
API
added
into
the
picture.
Now
that
won't
always
work,
but
the
goal
is
so
that
you
know
most
of
the
time
if
you're
just
adding
you
know
another
version
of
add,
for
example,
that
works
the
same
way.
B
B
C
C
Is
someone
supposed
to
get
the
fix
to
that
bug
by
moving
up
to
a
later
version
of
the
API
description?
In
other
words,
they
will
pick
up
other
changes
to
the
API
as
well,
which
they
may
or
may
not
want
to
pick
up,
or
are
you
thinking
of
somehow
patching
in
the
fix
to
the
earlier
version
of
the
API?
If
that
makes
them.
C
B
Algún
name
please
yeah
I
hadn't
thought
that
far
ahead,
I
guess
so
not
naive
answer.
Is
you
update
to
the
latest
version
of
the
API
and
that
contains
the
fixes
in
the
in
the
in
the
implementation,
I
guess
the
I
guess
it
would
be
possible
to
do
it
the
other
way
around,
but
that's
not
something
that
we've
traditionally
does
not
sort
of
part
of
our
the
way
we
develop
Omar
right
now,
so
I
think.
That's
that's
more
of
our
release.
Question,
which
is
an
important
one
to
answer.
B
Basically,
hadn't
thought
of
it
go
on
answer.
Sorry
right.
So
there
are
I
guess
there
are
some
alternatives
that
I
could
have
pursued
here,
so
it
could
have
used
something
like
swig,
for
example,
to
automatically
generate
alternative
language
bindings
from
the
existing
implementation
classes,
the
so
that
would
that
would
avoid
having
to
write
new
generators.
C
B
To
understand
and
one
of
the
things
that
I
didn't
want
to
make
it
hard,
because
it's
already
hard
enough
to
write
a
JIT,
compiler
or
a
native
code,
accelerator
I
didn't
want
to
make
it
any
harder
for
people
to
work
with
the
API
and
understand
what's
actually
going
on
under
the
covers.
So
you
know
with
the
with
a
few
hundred
lines
of
C++
code
per
generator,
most
of
which
is
boilerplate,
because
it's
C++
it's
actually
not
that
hard
to
write
fairly
transparent
API.
B
Is
that
just
do
the
shim,
the
shim
work
to
translate
the
the
objects
as
they're
passing
through
the
API,
and
it's
quite
easy
to
understand.
What's
going
on,
it
looks
nice
and
it
looks
nice
enough
in
a
debugger
that
you
can
kind
of
understand.
What's
going
on
andthat's,
that
was
valuable
enough
to
me
to
consider
or
to
go
down
this
path
of
having
my
own
Jenner.
Given
that
it's
not
a
tremendously
difficult
thing
to
do,
we
might
revisit
that
in
future.
I
guess!
B
But
but
that's
that's
where
it
stands
right
now:
okay,
so
that's
the
sort
of
first
area
of
focus.
The
second
area
focuses
to
integrate
with
this,
which
is
a
service
work.
That
I
talked
that
I
referenced
earlier,
so
I
thought
I'd
start
off
by
just
describing
what
I
mean
by
JIT
as
a
service.
Basic
idea
is
just
moving
the
JIT
compiler
out
of
the
runtime
process
into
a
service
that
lives
in
another
process,
either
on
the
same
machine
or
on
another
machine.
So
there
are
a
number
of
advantages
to
doing
that.
B
Well,
you
know
most
of
the
I
listed
them
here,
so
the
compiler
implementation.
Basically,
you
can
move
that
out
of
the
runtime
process,
which
means
you
don't
have
that
code
line
around
the
footprint
of
that
code
being
managed
there.
If
you
have
multiple
runtimes
runtime
processes
on
the
same
box,
that
means
you
can
sometimes
move
more
efficiently
place
that
code.
B
The
work
to
do
compilation
can
move
to
a
different
process,
maybe
even
on
a
different
machine.
You
can
move
the
footprint.
The
memory
footprint
that's
required
to
do
compilation
inside
a
runtime
to
a
different
process,
maybe
even
move
it
on
another
machine
and
those
two
of
those
to
those
last
two
or
actually
can
be
quite
significant
effects
right
it.
It's
quite
a
lot
of
work
to
do
compilation
and
that
can
be
just
disruptive
to
the
run
to
process.
B
Pardon
me
progress
in
in
the
runtime
where
the
compiler
is
running.
So
if
you
can
move
that
work
somewhere
else,
the
runtime
itself
can
more
effectively
make
progress.
Even
while
that
compilation
work
is
happening
somewhere
else
and
the
footprint
can
be
quite
substantial,
so
some
JIT
compilers
can
use.
You
know
up
to
hundreds
of
megabytes
at
the
time
of
doing
a
compile,
because
of
you
know
here,
if
you're
doing
a
high
optimization
compiled
that
takes
a
lot
of
memory,
so
moving
up
somewhere
else
can
also
make
the
runtime
process
run
a
lot
more
smoothly.
B
On
top
of
that,
it
also
offers
some
interesting
opportunities
to
share
JIT
compilation,
effort
across
multiple
runtime
instances
or
to
identify
optimization
opportunities
using
data
from
multiple
runtimes,
which
is
not
something
that
existing
JIT
compiler
technologies
really
have
access
to
because
they
live
in
one
inside
one
process
and
they
die
when
that
process
dies.
There
are
also
some
interesting
service
tests
and
maintenance
opportunities
that
arise
when
you're
when
you
have
JIT
operating
as
a
separate
process
that
I'm
not
going
to
focus
on
those
here.
Of
course,
it's
not
all.
B
It's
not
all
goodness
there
of
course
challenges
here
so
anytime.
You
move
the
compiler,
far
away
you're
going
to
have
higher
latency
z',
which
means
that,
if
communication
paths
and
and
that
could
mean
slower
ramp
up
because
you
won't
be
able
to
generate
compiled
code
as
quickly
anymore
also,
the
Omar,
compiler
or
intermediate
language
currently
has
no
persistent
form.
B
So
this
others
community
members
at
IBM
Canada
that
have
a
prototype
implementation
currently
working
through
some
kinks
in
that
prototype
and
preparing
to
open
source
it
in
the
next
couple
of
months,
hopefully,
and
that
will
be
open
source
that
both
eclipse,
open,
j9
and
it
eclipses
all
more
pieces
of
it
will
go
to
a
form.
The
goal
here
is
to
steer
the
fundamental
technology
parts
here
towards
the
Eclipse
Willmar
project,
for
example.
Establishing
the
compiler
service
communication
has
messaging
mechanisms.
B
Etcetra,
relying
on
other
open-source
projects
where,
where
possible,
it
was
that
a
couple
of
examples
there
that
we're
currently
using.
But
the
basic
idea
here
is
to
enable
more
development
in
the
open
around
this
just
as
a
service
technology,
and
so
that
we
can,
we
can
push
it
forward
not
just
for
Java,
but
also
within
the
eclipse
of
our
project,
and
so
the
open
question
here
is
so
we
know
this
is
coming.
B
You
know
how
can
more
runtimes
take
advantage
of
it
as
a
service
without
having
to
go
through
all
of
the
additional
implementation
cost
that
that
has
already
happened
for
Eclipse,
open
tree
9
and
tongue-in-cheek
jib
builder
to
the
rescue,
as
I
mentioned
before
the
compiler.
Il
has
no
fully
implemented
persistent
form,
which
makes
it
a
little
bit
difficult
to
generate
IO
in
the
client
and
then
spit
it
across
to
a
server.
It's
a
very
detailed
and
complex
data
structures.
B
Many
of
them
are
extensible
classes,
which
further
complicates
making
this
work
we're
trying
to
make
progress
on
this
nonetheless,
but
it's
not
there
quite
yet.
The
other
challenge
here
is
that
the
il
data
structures
tend
to
be
very
footprint
and
compile
time
sensitive
within
the
compiler.
So
adding
new
things
or
changing
them
in
aggressive
ways
can
distort
the
the
performance
profile
of
the
compiler.
We
prefer
not
to
do
that.
However.
We
have
this
just
builder
thing
and
it's
it's
API
is
significantly
less
complicated
and
potentially
easier
to
persist.
B
So
I've
opened
an
issue
18
18,
where
it
talked
a
little
bit
about
providing
a
record
and
replay
capability
for
the
JIT
builder
API,
where
the
idea
is
to
essentially
log
the
calls
that
happen
to
the
various
objects
in
the
JIT
builder
works
with,
or
that
the
client
creates
and
be
able
to
replay
that
log
off
of
of
events
on
the
server
side.
I
have
again
some
some
commits
that
are
hopefully
going
to
be,
at
least
in
my
private
repo,
shortly
to
define
what
I've
been.
B
For
lack
of
a
better
term
calling
je
bill
jet
builder,
il
binary
format,
which
I
think
is
an
enabler
for
using
good
as
a
service
for
all
jet
builder
based
clients.
That's
the
goal,
with
the
secondary
benefit
that
it
might
also
allow
the
Omar
project,
because
you
can
record
how
the
de
bill
is
being
generated.
B
So
having
this
table
format
would
allow
us
to
transport
some
of
the
effort
that's
been
put
into
generating
kits
for
other
languages
into
the
Omar
project
and
reflect
what
they're
doing
so
that
we
don't
regularly
break
people
hopefully.
So.
The
ultimate
goal
here
is
is
a
world
where
a
jet
build
our
client.
B
Even
an
existing
one
can
compile
either
in
process
or
out
of
process
with
a
statically
linked
compiler,
a
dynamically
linked
compiler,
a
remote
service
on
the
same
machine,
a
remote
service
on
another
machine
and
also
be
able
to
store
this
jeweller
piles
and
reload
them
to
be
compiled
either
in
or
out
of
process,
and
all
that
without
modifying
the
clients
use
of
JIT
builder.
So
it's
trying
trying
to
make
this
transparent
to
the
client
implementation.
B
Alright,
so
that
brings
us
to
the
third
basic
area
of
focus,
which
is
to
address
functional
gaps,
so
the
main
I
guess
the
one
overriding
point
here
is:
there's
more
work
here
than
people
I
know
of
to
work
on
it.
So
there's
there's
actually
quite
a
number
of
issues
that
are
already
open,
that
the
project
that
it's
been
capturing,
the
use
cases
the
people
are
caring
about,
so
of
them
have
gotten
attention
already.
Some
people
have
not.
B
Unfortunately,
the
point
of
this
slide
in
the
next
couple
are
to
sort
of
outline
the
things
that
I
would
very
much
like
to
get
focus
on
this
year
and
say
this
is
a
this
is
an
evolving
list
of
this
days
as
a
starting
point.
That's
kind
of
a
dump
from
my
brain.
If
you
have
different
ideas
or
different
needs,
or
you
think
other
things
would
be
much
more
important
to.
You,
then
feel
free
to
chime
in
on
the
issues
that
that
are
linked
here.
So
let
me
just
go
quickly
through
it.
B
So
there's
a
couple
of
platform,
specific
areas
that
that
you
know
chip
builder
doesn't
currently
work
very
well
on
the
power
platformer
on
the
Z
platform,
because
we're
missing
method
trampolines.
So
it
would
be
nice
to
fix
that,
and
Windows
currently
has
some
issues
as
well.
So
there's
a
couple
of
issues
there
around
enhancing
the
platforms
of
availability
for
jet
builder.
B
Excuse
me:
I
know
of
a
couple
of
projects
that
are
shaping
up
on
the
on
Z
and
on
on
other
platforms,
and
so
that's
what's
kind
of
driving
the
interest
in
that
Network
because
of
the
you
know,
the
the
great
enabling
potential
of
inlining
to
provide
performance
and
the
relative
simplicity
of
implementing
inlining
as
the
mechanism
at
the
JIT
builder
layer
there's
an
issue
there.
2398
that
describes
how
to
implement
inline
call
so
that
you
can
specify
a
call
that
you
would
like
to
be
inlined.
That
will.
C
B
The
or
inlining
the
compiler
inliner
it
just
uses
JIT
builder
to
do
the
inlining
directly
longer-term.
Obviously
it
would
be
better
to
have
the
Omar
compiler
driving
inlining
here,
but
until
we
get
to
that
point,
you
know
this
mechanism
is
relatively
easy
to
implement
and
it
would
allow
people
to
kind
of
play
with
what
inlining
heuristics
are
useful
for
them
in
their
in
their
particular
JIT.
B
B
So
the
method
metadata
is
a
data
structure
that
holds
information
about
a
compiled
method,
which
we
don't
have
a
very
well-defined
notion
of
right
now
in
Omar
it
would
be
a
place
where
you
would
hang
staff
and
register
Maps,
which
are
how
you
how
the
JIT
would
communicate
with
the
GC
on
what
registers
and
what
stack
locations
contain
live
objects
from
it
built
their
standpoint.
Once
we
have
that
better
integration
will
want
to
surface
the
notion
of
a
manatee
pointer
as
an
il
a
primitive
I'll
type
in
shipbuilder.
B
B
There's
a
link
at
the
bottom
of
this
slide
here.
That
just
shows.
Basically,
every
issue
at
at
the
Eclipse
of
our
project
that
has
to
do
with
JIT
builder
has
been
tagged.
That
should
build
our
label,
so
you
can
find
them
relatively
easily
and
if
anybody
wants
to
sign
up
to
help
with
any
of
these
were
perfectly
willing
to
help
people
make
progress
on
them.
So,
but
there
are
a
variety
of
different
ways
that
you
could
actually
reach
out
to
help
so
obviously
we're
very
interested
in
growing
our
user
base.
B
Please
let
us
know
that
too.
So
we
can.
We
can
try
to
fix
that.
If
you
have
anything
that
you'd
like
to
see
that
isn't
listed
here,
please
feel
free
to
to
make
suggestions
or
or
if
you
know
you
have
other
ideas,
please
feel
free
to
propose
them.
If
you're
interested
to
pick
up
an
item
that
I've
listed,
that's
not
currently
active.
B
There
is
a
top-level
issue
2400,
which
I
somehow
managed
to
get
nice
round
round
numbered
issue
that
that
basically
summarizes
a
lot
of
the
issues
that
are
in
this
presentation
and
is
a
place
where
I'd
like
to
collect
people's
input.
So
if,
if
somebody's
working
on
something
and
you'll
feel
free
to
reach
out
there,
I
don't.
C
B
To
get
to
multiple
people
working
on
the
same
thing,
but
you
know
feel
free
to
document
what
you
want
to
do
there.
If
you
want
to
help,
you
know
other
ways
that
you
could
help
out
or
just
writing
down
your
experience,
trying
out
chip
builder
and
let
us
know
how
it
goes
right.
It's
as
I
said
it's
meant
to
be
an
easy
to
use
library.
So
if
it,
if
it
somehow
wasn't
easy
for
you,
let
me
know
when
we
can
try
to
fix
that
and
I'll
build.
B
We
reiterate
the
issues
that
I
mentioned
earlier.
Is
that
there's
a
language
that
you
want
to
use
shipbuilder
from
feel
free
to
list
that
there
so
and
even
if
you
just
want
to
refer
this
project
to
someone
you
think
would
be
interested
in
it.
That's
actually
helping
us
out.
Quite
a
lot.
You
know,
word
of
mouth
is
a
very
powerful
thing
and
we're
will
always
welcome
a
new
face
or
any
voice
at
the
at
the
project,
and
we
really
look
forward
to
continue
to
grow
the
Omar
community.
So.
B
All
ways
that
that
you
can
help
if
you,
if
you
would
like
to
and
finally,
if
there's
any
other
feedback,
downs
or
the
variety
of
different
ways
to
reach
me,
that's
my
email,
my
twitter
handle
you
can
reach
out
at
the
Omar
project
itself
at
our
github
site,
raising
an
issue
or
any
of
the
issues
that
I
mentioned
again.
2400
is
the
top-level
issue
for
forge
it
builder
in
2018,
so
find
that
or
you
can
even
reach
out
at
our
Omar
dev
mailing
list,
which
occasionally
people
use,
but
there
are
always
people
listening.
A
A
A
Right,
okay,
so
that
was
our
pretty
much
our
only
topic
for
this
week.
So
hopefully
the
recording
actually
succeeded
this
week
so
that
I'll
get
that
up
on
our
YouTube
channel
tonight
and
publicize
that
so
you
can
watch
it
again
and
again
that
you're
at
your
leisure.
So
okay!
So
if
there's
no
other
comments
or
questions,
I
think
we'll
adjourn
the
meeting
now
thanks
everyone
for
attending
next
robot.