►
From YouTube: OMR Compiler Architecture Meeting 20180912
Description
Compiler Architecture Meeting agenda:
* New write barrier IL opcodes (#2948) [ @cathyzhyi ]
Please add any comments/questions to the GitHub agenda issue: https://github.com/eclipse/omr/issues/2954
A
A
C
B
B
So
I
would
like
to
expand
the
or
this
opcode
to
the
other
type
of
store
as
well,
and
we
will
keep
the
syntax
of
the
current
right
person
and
the
first
on
the
apron
we'll
need
to
keep
other
existing
children
of
as
the
original
load
and
also
might
be
adding
new
children
for
the
right
barrier
onto
for
the
information.
Actual
information
needed
by
the
extra
activity.
A
So
when
we
were
having
that
discussion
about
the
Reid
barrier,
you
were
saying
that,
unless
I'm
mistaken,
you
were
saying
that
we
actually
need
to
do
the
read
barrier
or
the
right
bear
before
the
actual,
read
or
write
operation
in
order
for
to
basically
intercept.
That
is
that
the
case
here
that
we
are
now
we
have
to
do
the
right
barrier
before
the
store.
B
A
D
D
Evaluating
you
evaluate
the
whole
things,
you
can
do
the
store
and
you
can
do
whatever
you
want
before
the
stories
don't
get
store
and
then
you
can
do
everyone.
After
the
store
majority
of
cases,
we
do
the
store
and
then
we
generate
some
code
to
hold
adjusting
I
think
in
some
GC
policies
real
time
we
do
something
we
call
the
GC
before
and
then
we
do
the
store.
So
it's
flexible
enough
to
to
do
whatever
you
want.
E
C
E
B
B
B
B
E
I
think
the
key
point
there
is
that
the
cases
where
a
right
barrier
explicitly
has
to
be
handled
there's
already
a
set
of
them
that
have
been
identified
because
there
is
already
a
right
barrier
for
reference
types
and
if
we
fail
to
perform
a
performance
transformation
because
we
wanted
to
store-
and
now
we
have
a
barrier,
then
you're
only
going
to
lose
performance
by
not
doing
that
transformation
and
we
can
go
through
and
fix
those
as
they're
found,
rather
than
needing
to
do
a
major
pass,
trying
to
find
them
all
up
front.
All
right.
E
The
the
more
worrying
wonder
if
there's
any
areas
that
would
not
handle
the
new
opcode
from
a
correctness,
point
of
view,
but
I
think
most
of
those
are
already
using
the
node
properties
and
things
like
that.
So
things
like
you
know,
use
desks
and
things
like
that.
So
those
I
think
should
already
be
okay,
because
they
can
already
handle
rate
barrier
or
store
for
reference
types.
B
B
B
B
D
D
D
C
D
B
D
D
D
B
C
A
A
C
B
C
A
A
A
E
E
A
It's
not
on
the
agenda.
It's
kind
of
a
late
last
minute
thing,
I
just
want
to
I
just
want
to
bring
in
here
I
did
want
to
talk
a
little
bit
about
shrink
wrapping.
It
did
come
up
as
a
we
had
talked
about
this
about
a
year
ago
as
to
whether
or
not
we
actually
want
to
remove
it
from
the
code
base.
There's
an
issue
created
I
unfortunate.
Remember
the
number
off
the
top
of
my
head.
It's
very
easy.
Diff.
A
2107
and
one
remember
that
up
Abbas
I
said
okay,
but
anyways
like
to
rekindle
that
and
actually
bring
that
to
some
kind
of
a
conclusion
other
whether
we
keep
the
code
with
justification
or
or
we
get
rid
of
it.
I,
don't
necessarily
want
to
come
to
a
any
kind
of
consensus
here,
but
I
think
we
do
need
to
sort
of
close
on
that
in
the
issue.
So
if
you
do
have
comments
or
thoughts
on
that,
please
please
add
those
to
the
to
that
issue.