►
From YouTube: OMR Architecture Meeting 20210415
Description
Agenda:
* Extensible class visibility and extension modifiers (#5913) [ @0xdaryl ]
* Remove unused IL opcodes (#5914) [ @0xdaryl ]
* Introduce Python dependency in OMR build (#5916) [ @0xdaryl ]
* Eliminate signed commit requirements [ @0xdaryl ]
A
A
A
Okay,
so
the
first
issue
that
I'd
like
to
discuss
is
issue
5913,
which
is
an
effort
to
provide
more
documentation
to
the
extensible
class
structures
that
we
that
we
have
so
one
of
the
challenges
that
we
have
with
the
fact
that
the
extensible
class
organization
is
essentially
a
static.
Polymorphic
structure
is
that
the
c
plus
language
class
modifiers
don't
have
the
same
effect
on
that
kind
of
a
structure
as
they
would
on
a
more
normal,
dynamic,
polymorphic
hierarchy.
A
A
A
A
So
it's
it's
it's
basically
getting
you
know.
Full
visibility
throughout
protected
behaves
like
a
so
there
is
an
analog
between
these
visibility,
visibility,
modifiers
and
the
actual
c
plus
plus
ones.
It's
just
trying
to
adapt
them
to
the
extensible
class
hierarchy,
so
protected
makes
the
member
only
visible
within
the
concrete
class
hierarchy,
so
everything
up
to
and
including
the
where
the
concrete
class
of
the
extensible
class
is
defined,
so
that
that
that
member
is
visible
anywhere
there.
A
The
intention
here
is
that
the
public
and
protected
modifiers
will
form
the
public
api
for
the
extensible
class.
So
if
somebody
is
interested
in
seeing
what
functions
are
available,
which
what
functions
can
be
extended,
that
sort
of
thing
you
can
learn
that
from
looking
at
the
public
and
and
protected
members,
there
isn't
an
omr
private,
mainly
because
there
isn't
really
a
need
for
it,
but
could
certainly
see
that
just
for
consistency
we
may
want
to.
A
A
A
C
Are
also
so
darryl
sorry,
can
I
ask
a
question
about
that?
Abs?
Absolutely
the
so
I
guess
if
I've
understood
correctly,
the
omr
protected
is
for
things
that
are
accessible
to
static
extensions
of
the
class,
but
not
to
further
derived
classes
that
are
are
derived
from.
So
we
have
our
static,
most
derived
thing
and
only
things
on
the
path
to
that
static.
Most
derived
thing
have
access
to
omr
protected,
but
then,
if.
D
C
A
A
public
is,
it
can
be
accessed
by
the
by
the
class,
that's
deriving
from
the
concrete
class
or
it
can
be
accessed
directly
from
the
concrete
class.
So,
let's
say
in
the
case
of
let's
say
the
code
generator
you
create
a
tr
colon
colon
code,
generator
object,
you
can
access
public
members
from
that
code,
generator
object,
but
you
can't
access
protected
members
from
that
code.
Generator
object.
A
If
you
went
and
extended
that
code
generator
object
with
something
else.
Maybe
code
generator
isn't
a
great
example
here.
But
if
you
went
and
extended
it
for
something
else,
you
could
still
access
the
public
members
from
that
extension.
But
again
you
also
couldn't
access
the
the
protected
members
either.
C
C
B
A
A
So
there
may
there
may
not
need
yeah,
so
there
may
not
need
to
be,
which
would
be
a
good
thing.
Actually,
there
may
not
need
to
be
a
visibility
modifier
for
public,
but
okay,
I'll
work
on
that
in
the
back
of
my
head
just
to
see,
if
I
can
think
about
what
my
initial
reasoning
behind
that
was.
So
thanks
is
it
just.
A
F
A
A
E
G
A
A
A
A
Okay,
the
other
thing
that
I
was
thinking
about
was
introducing
some
extension
modifiers
as
well.
So
there
isn't
the
notion
of
well
you
we.
We
can
introduce
the
notion
of
like
a
pure
virtual
function,
but
if
we're
trying
to
avoid
virtual
functions,
obviously
using
a
pure
virtual
function
is
not
is
not
the
way
to
go
so
that's
kind
of
where
the
omr
abstract
modifier
comes
in.
A
So
it's
basically
something
that
you
use
on
a
function
to
indicate
that
it
must
be
implemented
by
some
class
extending
it,
whether
that
implementation
is
actually
within
the
ex
the
the
extensible
class
itself.
So,
for
example,
you
define
it
in
a
base
class
and
some
architecture
comes
along
and
actually
provides
the
implementation
of
that
or
if
it's
something
that
a
project
that
is
extending
the
the
the
the
the
omr
base
class
needs
to
provide.
A
But
the
intention
with
that
abstract
is
that
it
must
be
implemented
before
the
concrete
class.
If
that
makes
sense,
so
it
has
to
be
provided
either
by
an
architecture
or
a
project,
and
there's
a
few
examples
of
that
right
now
in
the
in
in
the
code
and
where
we
just
provide
a
dummy
implementation
and
then
usually
add
an
assert
in
the
code
that
it
must
be
implemented.
C
Sorry,
I
guess
in
the
if,
if
the
concrete
class
wants
to
defer
the
that
decision
of
of
what
implementation,
it
is
to
run
time,
it
could
declare
a
a
virtual
method
right,
and
that
would
still
be
I
mean,
even
if
it
was
a
pure
virtual
method,
still
any
any
instance
that
you
have
that
it
would
have
to
be
an
instance
of
a
derived
class.
That
really
does
have
a
an
implementation,
or
I
guess,
as
long
as
it's
an
instance
method
anyway,
right.
C
No,
I
not
in
general
just
that
the
requirement
that
some
class
or,
like
you
know,
eventually
the
concrete
class
provides
an
implementation,
could
be
satisfied
by
the
concrete
class
if
it
wanted
to
by
even
a
pure
virtual
function.
If
it's
an
instance
method,
I
think
right,
it
doesn't
cut
off
that
avenue.
A
C
C
B
C
A
A
A
Omar
override
is
a
decoration
that
is
used
in
a
base
in
a
in
a
derived
class
to
indicate
that
this
particular
function
is
being
overridden,
or
this
is
an
override
of
a
function
in
a
base
class.
It's
really
there
to
document
the
fact
that
you
know
this
is
not
a
new
function.
This
is
really
just
an
implementation
of
something
from
the
base
class
from
a
base
class,
so
it
makes
it
makes
the
code
a
bit
readable
to
understand
that.
C
A
A
Maybe
I
do
want
to
poke
up,
so
I
guess
I
do
want
to
just
open
it
up
for
discussion
here,
whether
or
not
people
think
these
are
necessary.
Whether
or
not
this
is
the
wrong
approach.
Whether
there's
alternate
solutions
to
achieving
what
I'm
trying
to
achieve
here,
you
know
different
semantics,
whatever
I'm
certainly
open
to
some
discussion
on
this
on
this
point,.
G
A
E
We
would
have
some
advantages,
I
think,
also
in
terms
of
flushing
out
what
stakeholders
are
depending
on
I
mean.
Obviously
a
stakeholder
could
take
omr
and
and
make
whatever
patches
they
want
on
on
top
of
the
base
stuff.
But
if
they
want
to
fold
any
of
that
back
into
the
main
project,
it
becomes
very
obvious
when
they've
added
an
extension
point
and
gives
the
project
a
chance
to
identify
and
and
and
evaluate
that.
C
E
E
B
A
G
C
A
A
Is
one
of
the
consequences
of
adding
these
modifiers
is?
Is
the
is
the
appearance
of
the
code?
It
could
potentially
make
the
code
look
a
lot
busier
than
it
is,
but
I
tend
to
think
that
it's
a
good
kind
of
busy,
as
opposed
to
just
adding
some
other
noise
into
the
into
the
mix
like
it
actually
is
a
useful
documentation.
A
I
think
clang
actually
allows
you
to
have
groups
like
you.
Can
group
attributes
together,
like
you,
could
have
a
public
sec,
I'm
not
sure
what
the
term
is,
but
you
can
have
like
a
public
section
here,
for
example,
where
you
define
all
the
public
ones
that
and
that
that
attribute
will
apply
to
everything
in
that
section,
scope
or
something.
You
can't
remember
what
the
term
is
they
use
for
that,
so
that
could
possibly
some
be
another
option.
D
A
G
A
C
A
It
I
mean
the
use
case
was
if
there
was
some
function
that
was
defined
in
a
base
class,
but
it
was
only
intended
to
be
used
within
the
extensible
class.
You
didn't
want,
like
you,
kind
of
wanted
to
be
private
within
that
hierarchy
like
within
the
the
actual
concrete
class
somewhere
in
that
hierarchy,
but
you
didn't
want
to
expose
it
to
consumers
of
that
concrete
class.
A
G
I
actually
do
have
one,
and
this
is
related
to
when
I
was
adding
the
load
store
handler
into
the
power
code
gen.
One
thing
I
ended
up
having
to
do
was:
I
had
to
split
that
into
two
separate
extensible
class
hierarchies,
one
of
which
contained
only
public
stuff
and
one
of
which
contained
only
protected
stuff,
just
to
specify
that
a
lot
of
the
protected
stuff
is
just
sort
of
used
by
the
public
stuff.
C
There
so
what
what
kind
of
thing
was
it
in
there?
If
you
don't
mind
me
asking,
because
I'm
trying
to
imagine
the
difference
between
somebody
who
comes
along
and
extends
your
class
in
a
way
that
that
affects
the
concrete
class
versus
somebody
who
comes
along
and
derives
from
it
in
a
sort
of
a
runtime
polymorphic
way.
I
guess
like,
what's
what's
the
difference
between
those
two
consumers
of
the
class
that
are
like,
where
one
should
have
access
to
something
that
the
other
should
not?
C
G
At
the
very
least,
we
could
guarantee
that
omr
does
not
accidentally
do
that
in
some
way,
a
derived
project
may
decide
that
they
want
to.
They
want
to
make
that
public,
but
by
protecting
these
things
we
allow
we
allow
them
to
be
used
in
a
default
implementation
of
a
potentially
extended
endpoint
that
could
be
extended
in
such
a
way
by
the
derived
project
that
calling
the
internal
part
directly
is
no
longer
okay,.
A
And
if
they're
extending
the
con,
if
they're
extending
the
concrete
class
that
wouldn't
be
allowed,
though,
but
if
they
are,
if
they
are
adding
their
own
project,
specialization
of
that
or
if
they're,
adding
in
their
own
project,
specialization
some
function.
That
is
going
to
be
using
that
member,
then,
yes,
that
would
be
allowed.
A
B
E
B
C
A
Okay,
I'm.
I
will
clean
this
up
with
the
the
with
some
of
the
questions
and
comments
that
have
that
have
come
up.
I
guess
the
one
thing
that
you
know
the
the
like
the
whole
thing
with
extensible
classes
that
we're
kind
of
building
something
on
top
of
an
existing
of
on
on
top
of
the
existing.
You
know
c,
plus
plus
rules.
We
hadn't
really
thought
much
about
things
like
friend
classes
and
and
that
and
what
kind
of
access
they're
they're
allowed
to
have.
A
A
A
A
Some
of
them
only
have
evaluators
on
certain
architectures.
Many
of
them
don't
have
any
evaluators
at
all.
All
of
these
kind
of
floating
point
intrinsics.
I
guess
you
could
call
them,
they
look
like
they
do
something,
but
they
actually
don't,
because
they
actually
require
a
function
to
be
called,
but
that
function
doesn't
exist
anywhere.
A
So
basically,
these
are.
These
are
all
vestigial.
I
would
consider
them
to
be
vestigial
opcodes
that
we
can
get
rid
of
my
argument
for
getting
rid
of
them
as
opposed
to
pardoning
them
would
be
if
somebody
in
the
future
did
find
an
actual
use
for
them,
they
would
have
to
come
with
proper
documentation.
A
You
know
describing
what
the
semantics
actually
are.
How
are
we
going
to
implement
them
on
the
different
platforms
and
and
do
other
you
know,
provide
test
cases
for
them
as
well?
So
that's
that's
where
my
thinking
was
there.
Merge
new
is
one
that's
been
around
for
many
many
years
came
from
the
open,
j9
space.
There
actually
is
a
means
of
producing
it
in
in
open
j9,
but
I
don't
believe,
there's
even
an
evaluator
for
it
anymore,
but
I
remember
this
particular
op
code.
A
We've
never
seen
any
positive
benefit
from
that,
and
I
think
we
even
saw
some
regressions
with
it.
It's
only
implemented
on
x86,
I
believe
just
32-bit.
Even
so
it's
I
don't
think
it's
anything,
that's
that
would
preclude
us
getting
rid
of
it
so
anyway,
this
is
my
list.
Any
dissenting
opinions,
I
guess,
is
what
I'm
looking
for.
A
A
A
A
A
C
A
A
A
A
A
A
A
I
mean
there
is,
you
know:
python
does
run
on
zos
we're
not
completely
broken.
There
may
be
some
aspects
or
there
may
be
some
packages
that
that
are
problematic,
but
so
far
when
we've
stayed
within
the
lines,
we
haven't
really
had
any
problems
yet
with
with
with
python
on
zos.
So
I'm
I
think,
you're.
I
agree
that
we
have
to
be
cautious,
but
I
don't
know
if
that
is
one
that
will
actually
preclude
preclude
this.
A
The
the
outcome
by
the
way
of
this
particular
issue
is
really
just
a
rubber
stamp
that
the
omar
community
has
discussed
this
and
has
agreed
that
that
this
is
the
direction
that
we
want
to
go
in
and
it
can
be
used
as
an
issue
that
we
point
at
other
projects
to
say
that
you
know
this
is
this
is
why
we're
doing
this?
This
is
when
we
decided
that
so
it's
more
of
a
bookkeeping
kind
of
thing.
A
It's
it's
yeah,
it's
it's
an
enabling
feature
for
that.
I
know
that
there
has
been
some
interest
from
openj9
in
discussing
the
options,
implementation
that
we
have
not
necessarily
the
like
precluding
the
the
use
of
python,
but
maybe
how
some
of
that
has
been
structured,
but
it
I
think
it
is
certainly
a
step
in
that
direction.
There
are
other.
There
are
actually
many
other
examples
of
where
we
can.
We
can
auto
generate
some
of
the
data
structures
that
we
have.
A
That's
that's
currently
split
across
different
projects
like,
for
example,
the
like
the
value,
the
the
value
propagation
table,
the
simplifier
table,
the
you
know
that
even
the
tree
evaluated
tables
are
are
split
like
that
there
are.
There
are
a
few
things
that
we
can
a
few
data
structures
that
we
can
synthesize
that
way.
Even
the
op
codes
right,
dial
up
codes.
A
A
D
A
Okay,
so
if
there's
no
discussion
on
that,
the
last
topic
that
I
wanted
to
bring
up
is
something
that
was
already
discussed.
I
think
on
slack.
So
I'm
not
sure
if
there's
any
real
thing
to
bring
up
here
other
than
just
to
maybe
highlight
it
for
everyone's
awareness
and
just
get
general
agreement
that
this
is
the
the
direction
we
want
to
go
in.
A
So
the
eclipse
foundation
has
changed
their
their
process
on
contributions
to
the
to
to
the
to
the
code
base
where,
in
the
past,
they
used
to
require
that
all
the
commits
were
had
a
signed
off
by
line
that
contained
an
email
address
of
somebody
that
had
signed
the
eclipse
contributor
agreement
and
they
provided
tools
where
they
could
check
on
on
every
commit
that
was
checked.
That
was,
that
was
pushed.
A
They
could
check
to
see
whether
or
not
the
email
address
was
from
a
person
that
had
signed
the
eca
and
they
would
flag
it
otherwise.
So
it
was
a
handy
way
to
to
let
people
know
about
that.
They've
decided
to
approach
that
problem
with
a
different
solution,
so
they're
not
going
to
require
the
signed
off
by
footers
anymore,
instead
they're
going
to
go
by
the
the
email
address
of
the
author
of
the
commit
to
determine
this.
A
So
as
a
as
a
project,
we
were
requiring
that
that
the
signed
off
by
footers
are
are
mandatory
on
on
each
commit,
mainly
driven
by
the
requirements
of
the
eclipse
foundation.
So
if
they
don't
require
it,
the
question
is
whether
or
not
this
project
should
require
it.
So
I
think
the
consensus
on
slack
at
least,
has
been
no,
it's
just
an
unnecessary
step
that
that
people
have
to
go
through
and
provided
that
eclipse
is
going
to
be
providing
a
replacement.
A
If
they
are
able
to
provide
that,
then
we
I
I
I
think
we're
still
going
to
be
in
pretty
good
shape
if
they
don't
provide
that,
then
obviously
we're
going
to
have
to
do
some
manual
work
to
figure
that
out,
but
but
I
I
believe
they
are
providing
such
a
tool
going
forward
so
yeah.
So
the
the
the
topic
for
discussion
is
whether
or
not
we
should.
We
should
move
away
from
the
use
of
the
signed
off
by
requirement
in
our
commits.