►
From YouTube: OMR Architecture Meeting 20200130
Description
Agenda:
* OMR Garbage Collector (GC) Technology Roadmap [ @rwy0717 ]
A
A
B
Then
I'm
going
to
start
to
talk
a
little
bit
more
abstractly
about
ways
that
we
could
take
the
garbage
collector
in
the
future
and
the
sex
is
going
to
be
more
or
into
that
pursuing
the
goal
of
making
a
Walmart
generic
and
usable
to
more
than
just
Java
and
then
finally,
I'll
I'm
going
to
talk
a
little
bit
about.
You
know:
high-level
concepts
and
the
overall
architecture
of
the
TCC
of
the
future
and
one
potential
way
that
we
might
be
able
to
take
it.
B
But
before
I
get
into
that
I
guess.
I
should
just
say
a
few
things
about
like
what
our
goals
are
in
the
garbage
collector
over
the
next
year
and
for
the
most
part
we
want
to
keep
doing
the
same
things
that
we've
always
been
doing.
You
know
it's
the
needs
of
j9
and
improvements
that
we're
making
to
j9
that
are
happening
in
a
Walmart
and
continue
to
make
the
garbage
collector
better
and
better.
So
we're
just
in
a
lot
of
ways
we're
just
going
to
kind
of
keep
doing
that,
but
as
well.
B
We
want
to
focus
on
moving
even
more
technology
from
j9
to
OMR
and
that's
going
to
help
us
as
well
as
going
to
provide
new
opportunities
for
paying
down
technical
debt
and
finding
new
ways
to
sort
of
clean
up
our
code
and
sort
of
heal
the
gap
or
six
fix
all
the
damage
that
was
caused
by
you
know
splitting
the
garbage
collector
in
half
all
those
years
ago.
We
started
bill
maher
project
and
then,
of
course,
by
paying
down
technical
debt
moving
more
technology
into
Lamar.
B
So
now
I'm
just
going
to
talk
about
the
things
that
we're
working
on
or
we'll
be
working
on
in
the
coming
year.
So
the
first
thing
that
I'm
going
to
talk
about
are
the
auto
comp
builds
and
how
we
really
just
want
to
get
rid
of
them,
not
really
just
a
GC
thing.
This
affects
everybody,
but
you
know
by
the
in
this
year.
We
really
need
to
get
rid
of
those
builds
and
move
the
remainder
of
versity
builds.
B
You
see,
make
need
to
make
sure
that
DDR
support
is
there
so
that
you
know
j9
is
able
to
make
that
transition
to
see
make
and
once
we
are
able
to
get
rid
of
the
auto
comp
builds
I.
Think
that
that's
going
to
enable
us
to
sort
of
clean
up
the
structure
of
our
libraries
and
some
of
our
source
codes
and
in
particular,
I'm
thinking
about
how
Omar
code
or
how
the
core
or
Mar
libraries
have
circular
dependencies
around
startup.
B
Yeah,
so
you
know
just
build
system
improvements
and
we're
looking
at
migrating.
The
metronome
garbage
collector
to
om
our
metronome
is
the
ill-timed
garbage,
collector
technology,
g9
and,
and
what
it
does
is.
It
provides
a
guarantee
about
the
upper
bound
or
pause
times
in
the
collector.
But
in
order
to
make
that
work,
it
has
a
lot
of
places
a
lot
of
requirements
on
the
consuming
application,
which
I
mean
in
this
case
would
be
j9
and
as
well.
B
It's
sort
of
a
bit
of
an
alien
when
it
compared
to
the
other
garbage
collectors
and
that
there's
not
a
lot
of
code
shirring
because
it
has
to
do
things
in
different
and
unique
ways,
but
we're
hoping
that
once
we
can
migrate
metronome
to
Omar,
we
can
start
to
find
places
to
clean
up
the
code
and
kind
of
common
eyes.
Some
of
the
core
technology
that
the
collectors
actually
built
on
a
metronome
is
building
on
technology.
That's
already
been
moved
to
Omar,
including
the
segregated
heap
code
and
snapshot
at
the
beginning,
barriers.
B
We're
working
on
enabling
runtime
compressed
references
so
compressed
references
are
a
shorter
encoding
for
references,
and
we
do
that
by
placing
an
upper
bound
on
the
maximum
address
of
the
heap,
and
then
we
can
play
you
know:
object
alignment
tricks
to
sort
of
stretch
that
limit
a
little
bit
further.
Historically,
this
is
always
been
a
compile
time
decision,
but
in
order
to
it
work
to
make
this
a
run
time
decision
go
ahead,
check
what
mode
or
were
in
like.
B
B
And
then
this
is
kind
of
a
big
slide
that
this
is
just
listing
out.
Some
of
these
functional
improvements
that
we're
looking
to
make
to
the
standard
garbage
collector
the
standard
garbage
collector
sort
of
refers
to
our
you
know
our
global
collector,
our
generational,
scavenging,
collector
and
and
concurrent
collector,
as
well
as
compacted.
So
all
these
technologies
get
sort
of
proofed
under
this
umbrella
standard,
GC,
special
one,
so
we're
looking
at
using
snapshot
at
the
beginning
barriers
in
concurrent
GC.
B
So
right
now,
current
collector
has
to
sort
of
interleaved
GC
work
with
the
mutator,
which
is
like
a
running
application,
and
we
need
to
do
some
amount
of
bookkeeping
to
track
how
the
object
graph
is
updated
as
the
program
runs
and
they
exist,
and
we
call
that
that
code
that
tracks,
how
the
object
graph
updates.
We
call
those
barriers
and
existing
barrier
relies
on
this
card
mechanism,
and
it
requires
this
sort
of
long
phase
at
the
end
of
a
concurrent
collection
in
order
to
sort
of
finally
finish
up
the
deflection
and
snapshot
at
the
beginning.
B
Barriers
are
a
little
bit
more
expensive.
It's
a
little
bit
more
of
an
expensive
form
of
bookkeeping,
but
it
may
allow
us
to
have
a
shorter
stop
the
world
phase
at
the
end
of
the
corruption
we're
looking
at.
You
know,
just
generic
improvements
to
the
concurrent
scavenger.
You
know
honestly,
as
well
as
to
all
the
collectors.
B
One
interesting
thing
that
works
in
that
investigating
is
the
possibility
of
changing
the
order
that
we
scavenge
objects.
So
we
can
prioritize
fields
that
are
haunt
or
accessed
more
frequently
in
order
to
co-locate
objects
that
are
used
together
to
co-locate
them
onto
the
heat,
and
you
know
this:
should
this
should
play
better
with
you
know,
memory
cache
isn't
hopefully
give
us
a
nice
boost
performance.
B
So
you
know,
if
you
have
a
machine
that
has
you
know
it's
a
neat
wave
machine
has
indican
run
decay
spreads
concurrently,
then
the
GC
will
create
seven
slave
threads
plus
a
master
and
in
this
new
world
of
virtualization
the
factors
of
don't
always
own
the
entire
facility.
So
well,
we
may
be
bringing
up
a
prince.
We
may
only
have
50%.
C
B
So
we
have
this
problem
right
now,
where
we
can
only
have
a
single
garbage,
collector,
enabled
or
being
built
in
my
single
bill
tree.
And
if
you
compare
that
to
the
compiler,
we
have
there's
a
library
of
cement
utilities
and
others
to
sort
of
define
in
order
to
sort
of
create
or
to
find
do
get
libraries
and
that
sort
of
enabled
the
compiler
to
have
a
test
compiler
built
alongside
Jib
builder,
which
is
built
alongside
tril.
So
it
would
be
interesting
to
investigate
something
like
that
for
the
garbage
collector.
B
The
obvious
alternative
is
that
we
rely
on
multiple
build
trees,
so
we
like
you
would
continue
to
do
one
garbage
collector
for
Bill,
but
maybe
we
make
some
scripts
to
make
that
easier
to
orchestrate.
So
a
person
can
sort
of
you
know,
type,
don't
flash
bills
and
build
a
jam,
a
garbage
collector
or
the
default
garbage
collector
or
a
test
garbage
collector.
B
We
really
need
to
focus
on
in
the
GC
focus
on
simplifying
the
starter
procedure,
because
in
the
garbage
collector
we
sort
of
have
to
interleave
start
up
with
the
different
components,
and
you
know
in
order
to
call
some
guys,
we
need
to
have
party
initialized
objects
elsewhere.
So
sometimes
we
end
up.
You
know
bringing
up
fake
environments
or
fake
objects
in
order
to
sort
of
satisfy
the
requirements
of
the
API,
and
we
have
you
know
circular
dependencies
between
components.
So
this
component
a
parcel
of
e
a
and
we
really
it's.
B
B
We
would
also
like
to
take
a
more
configuration
based
approach
to
startup,
so
it
might
mean
building
a
support
library
that
can
identify
startup
parameters
as
well.
As
you
know,
how
was
that
parameter
set
is
a
hard
limit,
a
lower
limit.
Is
it
undefined?
Do
we
care
and
it
would
be
nice
to
be
able
to
track
configuration
values
back
to
how
they
were
set,
so
that
I
could
say?
Well,
your
minimum
memory
is
bigger
than
your
maximum
memory
usage.
So
why
are
these
variables
set
like
that?
B
So
what
limitation
in
a
collector
today
is
that
objects
have
to
have
a
conforming
header,
which
means
that
the
header
has
the
correct
layout
with
a
correct
set
of
flags
in
the
right
place,
and
there
are
probably
other
ways
to
represent
those
metadata,
and
what
we
like
to
do
is
replace
this
direct
accessing
of
the
the
flags
with
new
API
is
in
the
object
model
so
that
an
application
could
implement.
You
know
their
own
mechanism
of
bookkeeping,
for
these
object
properties.
B
B
B
B
B
Implementing
allocation
api's
can
actually
be
quite
tricky
because
you
often
have
to
interleave
allocation
with
object.
Initialization
with
you
know,
concurrent
garbage
collection,
work
with
potentially
I,
don't
know
zero
in
pages,
so
we
need
to.
We
need
to
sort
to
help
to
define
a
generic
API
that
helps
people
build
up
this
allocation,
API
and
interleave.
B
And
somebody
we
don't
really
have
any
helpers
for
barrier
related
functions,
so
again,
barrier
related
functions
are
they
help
inform
the
garbage
collector
about
how
objects
are
updated
and
we
provide
some
really
rough
area
code,
but
not
really
anything
that
could
actually
be
used,
so
science
has
to
implement
their
own
code
and
that's
extremely
difficult
to
get
Buyten
j9
has
a
very
large
collection
of
aerial.
A
P
is
so.
What
we
would
like
to
do
is
find
a
way
to
take
that
and
genera
Phi
to
narrow
Phi
it.
B
B
This
last
point
is
a
bit
of
a
stretch,
but
it
might
be
possible
to
add
some
kind
of
tool
in
to
help
developers
check
that
barriers
are
in
place,
they're
easy
to
update
an
object
and
forget
to
to
do
that
through
a
barrier,
and
these
kinds
of
errors
are
commonplace,
but
also
really
difficult
to
track
down.
So
some
may
be
some
form
of
static
or
runtime
analysis.
The
health
check
areas
would
be
really
cool.
B
Okay,
I
had
to
put
this
one
here
and
I.
Don't
really
know
what
this
would
look
like,
but
we
really
need
to
think
about
ways
that
we
can
integrate
or
provide
some
basic
integration
between
the
garbage
collectors.
Piler
people
could
go
into
their
own
time,
I'm
imagining
some
basic
just
over
support
for
effective
references
and
if
we
can
define
some
kind
of
standard
representation
for
stack
maps
and
I
assume
that
would
be
standard
standardized.
It's
like
a
standard,
binary
format
that
was
platform
specific.
B
C
B
There's
a
huge
variety
in
virtual
machine,
implementations
and
I
think
you
know
at
a
certain
point:
we
have
to
face
the
reality
that
there
is
no
one-size-fits-all
solution,
so
we
have
to
start
thinking
about
like
who
are
we
writing
this
for
and
what
does
their
virtual
machine
actually
look
like,
but
you
know
you,
we
can
go
for
it
anyways.
If
we
can
find
some
place
to
relax
assumptions
about
the
runtime
you
know.
Maybe
we
didn't
really
need
a
specific
cart
like
virtual
machine
that
we're
targeting,
but
that's
really.
B
To
do
we
started
as
much
as
possible,
but
we
have
to
balance
this.
This
need
of
providing
a
sane,
useable,
API,
with
with
the
different
assumptions
and
constraints
that
we
actually
make
about
the
virtual
machine
so
provide
a
high-level,
easy-to-use
API
for
languages
that
use
bitmaps
to
track
swamps,
that's
easy,
but
then
you
know
if
it
provides
a
generic
easy
to
use
API
that
could
track
that
could
track
any
kind
of
object.
B
So
we
take,
you
know
the
hardest
parts
that
we
think
we
think
might
be
common
for
a
lot
of
people
and
we
turn
those
into
libraries
that
people
can
pull
into.
So
this
would
sort
of
simplify
the
framework
element
of
Olimar
and
start
moving
towards
that.
The
library
based
approach
and
the
nice
thing
about
the
library
is
that
is
by
nature,
it's
opt-in.
So
if
the
abstraction
doesn't
suit
you,
you
just
don't
use
it.
B
But
you
know,
even
still,
it
may
be
impossible
or
too
difficult
to
work
with.
So
another
thing
that
we
can
do
is
start
to
organize.
The
garbage
collector
into
tiers
of
AP
is
where
we
have
lower
level.
Ap
is
that
people
can
target
if
they
need?
You
know
absolute
flexibility,
but
then
higher
level.
Api
is
if,
if
it
suits
them,
so
this
might
mean
something
like
extensible
classes
or
some
form
of
providing
a
default
implementation
that
could
be
override
by
the
user.
So.
B
What
this
might
look
like
is
where
we
have
our
core
garbage
collector
technology,
which
is
calling
into
these
low-level
delegates,
and
these
provides
the
like
the
low-level
needs
of
the
garbage
collector.
So
these
are
curls
with
most
basic
questions
and
there's
no
attempt
at
two-factor
and
promoted
to
clean
reusable
interfaces.
It's
just
like
I
need
to
spend
some
tree,
but
I
don't
know
how
so
language
gose
can
be
object,
and
what
we
can
do
is
build
these
optional,
adapter
libraries
and
it
could
be
I.
B
Guess
you
make
libraries
that
inject
sources
into
into
the
client
that
implement
those
delegates
in
terms
of
higher-level
interfaces.
So
if
you
like
Java
and
the
slot
iterator
API
works
really
well
for
you,
then
you
enable
the
adapter
implement
the
iterator
and
then
all
the
delegates
just
sort
of
get
implemented
for
free
I.
B
Think
that
you
know
you
see
this
looks
good
on
paper.
Maybe
it
doesn't
but
I
think
really
in
practice.
We
don't
know
how
well
does
the
work
in
order
to
build
the
kinds
of
abstractions
necessary
to
actually
implement
something
like
this?
We
might
end
up.
You
know
coming
up
against
the
limitations
of
c-plus,
a
language.
B
B
Of
writing
all
business.
Firstly,
so
maybe
we
can
help
or
try
to
reduce
the
risk
of
this
kind
of
work
by
taking
an
incremental,
on-demand
approach,
where,
when
we
find
that
one
particular
API
just
works
well
for
one
or
for
a
few
people,
but
doesn't
work
well
for
others,
then
we
start
to
break
it
down
into
layers
to
figure
out
where,
where
do
we
have
to
split
the
API
is
on
in
order
to
support
as
many
people
as
possible?
B
But
don't
you
know
only
take
that
approach
if
we
actually
need
to-
and
maybe
this
is
a
I-
don't
really
see
this
as
is
not
a
competing
practice
compared
to
extensible
classes,
I
kind
of
see
them
as
working
together
and
it
sort
of
be
implemented
in
terms
of
each
other.
But
maybe
this
is
a
stepping
stone
towards
beautifying
how
we
address
extensibility
in
a
more
and
that's
it.
That's
everything.
B
C
B
That
would
be
sort
of
like
the
near
future
items,
which
would
be
like
the
village
metronome
I
think
you
know
it
really
depends
on
which
particular
work
item
you're.
Looking
at
certain
things
like
retiring,
the
auto
comp
builds
I
think
that
we
could
accomplish
that
pretty
soon,
but
you
know
other
pieces
like
actually
migrating
mental
hard.
You
know
it
could
be.
Some
of
these
are
quite
big
jobs,
so
I
think
we're
looking
at
at
least
to
the
end
of
the
year.
B
B
C
B
Correctly
so
I
think
you
know
a
lot
of
the
things
that
we're
looking
at
in
the
distance
in
what
I
call
the
distant
future
sort
of
help
to
make
Omar
easier
to
work
with
and
there
yet
there.
It's
not
all
just
about
making
over
a
more
generic,
but
also
providing
more
functionalities
of
people
have
less
do.
A
You
have
any
particular
integrations
or
things
in
mind
that
will
serve
to
help
prove
out
the
ideas.
I
mean
things
like
the
waves
and
jet
ljb.
Things
like
that
have
certainly
had
an
impact
on
how
jet
builder
works
and
how
but
people
who
work
on
the
compiler
components
things
about
our
interactions
with
other
languages
outside
of
open
j9.