►
From YouTube: OMR Architecture Meeting 20210218
Description
Agenda:
* Initialize/shutdown portlib in JitBuilder and Test Compiler (#5798) [ @nbhuiyan ]
* Discuss state of Options rework (#3675)
A
A
B
B
B
So
at
this
time
the
only
use
of
the
old
library
in
the
omar
compiler
is
for
cpu
feature
detection,
but
we
still
need
a
fallback
mechanism
because
we
don't
have.
We
don't
have
the
port
library
in
all
use
cases.
But,
however,
with
jit
builder
and
test
compiler
ensuring
that
there
is
always
an
initialized
port
library,
we
can
get
rid
of
these
fallback
mechanisms
and
and
be
able
to
utilize
the
port
library
more
readily
and
right.
B
So
it
shuts
down
the
port
library
and
the
thread
library.
So
the
way
it
affects
typically
users
is
that,
in
addition
to
initialized
jit
and
initialize
youtube
options,
which
will
you
know,
the
initialization
that
you
saw
here
is
basically
going
to
be
part
of
initialize
it
and
initialize
it
with
options.
B
However,
users
of
jit
builder
should
be
able
to
initialize
their
own
port
library
and,
and
they
will
be
able
to
then
basically
initialize
the
jit
builder,
multiple
times
per
process,
because
right
now
one
of
the
constraint
is
that
the
thread
library
can
be
initialized
once
a
process.
And
if
a
user
is
using
a
jet
builder
like
initialization
builder,
more
than
once,
then
they
will
have
to
be
the
ones
handling
their
own
port
library,
initialization
and
shutdown.
B
B
A
B
B
C
C
The
fact
that,
if
you're,
if
you're
using
other
components
of
omar
with
jit
builder,
you
would
be
able
to
provide
a
port
library,
I
guess
I
guess
I'm
just
wondering
if,
if
the
initialization
of
the
port
library
needs
to
be
or
could
be
a
cmake
kind
of
config
option
which
would
allow
you
to
you
know
basically
make
that
four
percent
size
trade-off,
but
the
implementation
retains
its
complexity.
So
how
can
you
characterize
how
much
of
a
an
onus
that
is
to
to
for
us
to
be
checking
the
port
lib
in
the
code
base.
B
Well,
the
the
portlave
is
required
for
any
kind
of
use
of
the
full
library
so
because
well
basically,
the
check
the
the
way
it
is
done.
Is
we
check
for
whether
the
port
library,
member
of
the
compiler
app
class,
has
been
set
or
not?
And
if
it's
not,
then
we
have
to
use
a
fallback
mechanism
and
basically
have
to
have
a
duplicate
implementation
of
what
already
exists
in
the
port
library.
B
Yeah,
but
there
is
more
use
cases
that
we
can.
We
can
exploit
more
of
the
port
library
once
there
is
more
once
we
have
every
build
configuration
of
the
omar
compiler
actually
making
this
available.
So
then,
so
right
now
the
cpu
detection
feature
is
the
start,
but
there
is
a
lot
more
opportunity
for
using
that.
A
C
B
C
C
All
right,
so
I
guess
an
alternative
trade-off
that
we
could
force
on
people
would
be
not
just
I'm
just
fleshing
out
ideas
here,
not
necessarily
saying
this
is
what
I
think
we
should
do
necessarily,
but
we
could
also
make
a
port
library
a
configuration
level
option
where
the
backup
plan
for
not
having
a
port
library
is
you
get
some
dumb
default
for
whatever
code
would
otherwise
use
the
port
library
for
something
right.
So
in
the
case
of
cpu
detection,
it
would
be
we
default
to
the
oldest
processor.
B
C
Well,
I
mean
I
I'm
I'm
a
fan
of
the
cleanup
and
moving
like
not
having
duplicate
code
in
the
compiler
and
in
the
port
library
to
do
things
like
cpu
detection.
I
don't
think
we
should
maintain
multiple
copies
of
that
code,
but
but
I
am
cognizant
that
some
people
may
not
care
and
but
they
might
care
about
a
four
percent
size
increase
just
because
size
has
been
mentioned
before,
like
the
size
of
the
builder
library
has
has
been
a
mentioned
as
a
concern
point
for
some
people
in
the
past.
C
C
C
C
C
A
I
know
that
you
know
things
like
the
the
like
getting
the
process.
Pid,
for
example,
is
is
one
thing
there
might
be
some
memory
allocation
functions
that
need
to
get
that
could
be
used
through
the
part
library
file.
I
o
as
well,
I
suppose,
but
I
think,
taking
the
path
that
you'd
suggested
to
start
with
seems
like
a
reasonable
place
to
start
to
me.
B
I
agree
so
I
will
be
updating
the
request
and
have
like
a
build
configuration
that
is
going
to
allow
both
the
port
library
and
not
for
every
kind
of
scenario,
so
yeah
in
the
future
we
can
compare,
I
mean
we
can
assess
it
again
whether
we
can
completely
remove
the
need
to
have
these
two
mechanisms,
but
I
think
as
a
starting
point.
This
is
a
good
solution.
A
C
Okay,
so
I
apologize
for
not
having
taken
a
look
at
the
poll
request
before
this
discussion.
So
forgive
me
for
asking
such
a
simple
question,
but
is:
is
the
port
library
initialization
code
actually
in
the
omar
compiler
component,
or
is
it
in
the
jit
builder
and
test
compiler
components?
Isn't
the
jet
loader
and
test
compiler
components?
Okay,.
B
A
C
B
A
A
A
A
D
And
then
we
try
to
recompile
the
method
in
question,
whether
it's
recompiling
a
compilation
or
an
existing
jet
compiled
method.
We
trigger
another
compilation
of
that
in
the
event
that
we
crash
in
the
actual
jit
compiler,
we
will
attempt
to
re-trigger
the
original
compilation
and
before
we
do
that,
we
would
like
to
copy
the
options,
the
entire
set
of
options
that
were
used
for
the
original
compilation
to
ensure
that
we
can
reproduce
the
original
failure
with
tracing.
D
So
this
boils
down
to
being
able
to
copy
and
construct
the
j9
or
the
omar
options
object.
But
right
now
it
contains
a
whole
bunch
of
other
metadata
about
logs
and
other
weird
counters,
and
things
like
that.
It's
not
just
a
set
of
bits
that
represent
the
actual
options,
so
it's
impossible
today
to
copy
construct
that
object.
A
A
So,
unfortunately,
some
of
those
warts
are
still
in
the
code
and
we
don't
really
have
a
clean
solution
for
it.
So
one
of
the
things
that
that
we
started
to
work
on
was
a
much
cleaner
design
for
the
way
for
for
a
means
of
handling
and
processing
jit
compiler
options.
That
would
work
that
would
integrate
better
with
downstream
projects
that
want
to
consume
this.
A
You
would
describe
your
options
via
some
json
format
and
all
your
all
the
downstream
projects
could
describe
their
options
in
that
same
format
as
well
and
as
part
of
the
build
there
would
be
a
tool
that
would
go
and
grab
the
the
the
piece
from
omr
on
the
piece
from
it
and
all
the
pieces
from
the
downstream
projects
and
stitch
them
all
together
into
a
single
table,
and
that's
the
thing
that
the
build
would
would
use.
So
you
get
a
very
clean,
consistent
implementation
of
it
that
you
can
work
with.
A
So
actually
it
was
nazim
that
spent
a
bit
of
time
prototyping
this
and
we
actually
do
have
a
prototype
open
there
in
3675
that
that
does
work,
but
there
were
some
challenges
with
some
of
the
dependencies.
There
were
some
concerns
around
some
of
the
dependencies
that
that
this
kind
of
an
approach
would
would
would
would
have
so
omr,
for
example,
already
has
a
dependency
on
the
python.
A
Sorry
excuse
me:
jit
builder
already
has
a
dependency
on
python
for
some
of
the
interfaces
that
it
constructs
at
build
time,
but
down
other
downstream
projects.
Don't
currently
have
a
dependency
on
python,
so
there
was
the
the
the
the
one
challenge
about
enabling
this
sort
of
an
approach
would
require
all
downstream
projects
to
now
have
a
python
three
dependency
in
their
ci
pipelines.
A
So
this
has
been
discussed
in
the
past.
There
are
issues
open
that
where
we
have
talked
about
this,
this
sort
of
thing,
but
in
in
the
end,
though,
I
don't
think
that
we've
we've
taken
sort
of
the
next
step
to
to
push
this
work
forward
and
and
get
all
the
downstream
dependencies
resolved
and
get
sort
of
an
agreement
on
a
path
forward
in
those
particular
projects.
A
In
the
meantime,
there
may
be
some
other
approaches
for
processing
options
that
that
need
to
be
considered.
Some
other
ideas
have
have
perhaps
come
up,
so
that
kind
of
thing
is:
should
this
effort
get
rebooted
that
kind
of
an
effort
or
those
other
ideas?
I
think,
should
get
some
some
consideration
as
as
part
of
a
an
overall
design
here.
A
It
is
useful
for
synthesizing
tables
of
data
that
not
code
but
data
that
that
the
compiler
would
consume
so,
for
example,
things
like
the
the
the
tree
evaluator
tables
from
all
the
op
codes,
the
the
the
value.
Sorry,
the
value
propagation
table,
the
the
simplifier
table,
there's
a
you
know
like
a
gpu
code,
generator
table.
A
So
that's
where
things
are
at
at
the
moment
now.
One
thing
I
will
say
is
that
perhaps
some
of
the
things
that
you're
concerned
about
can
actually
be
done
independently
of
that.
So,
for
example,
you're
concerned
about
there
being
some
other
metadata
being
stuck
into
the
options,
object
that
perhaps
that
you
had
to
that
you
had
to
deal
with
when
you
were
doing
the
the
serialization
of
that
that
option
structure.
A
I
know
that
when
nazim
was
going
through
it,
he
did
discover
that
there
were
lots
of
things
in
there
that
perhaps
didn't
belong
in
the
options
object
at
all
that
should
live
in
a
in
a
you
know.
Perhaps
another
class,
perhaps
even
like,
like
an
extensible
class,
that
that
is
meant
for
that
kind
of
extension.
A
So
perhaps
there
are
things
that
we
can
do
to
the
options
object
as
it
exists
today
to
remove
some
of
the
things
that
are
causing
you
problems,
independent
of
coming
up
with
a
unified
structure
for
representing
objects
or
options,
so
I'll
just
pause
there
for
a
sec
to
double
check.
I
wasn't
on
mute,
good.
C
A
Yeah
yeah
there's
the
separation
of
like
one
of
the
things
I
believe,
and
I
keep
talking
in
place
of
of
nazim,
but
one
of
the
things
that
I
think
nazim
did
was
sort
of
separate.
The
notion
of
these
are
the
actual
options
that
you
would
specify
on
on
a
command
line
or
somehow
inject
into
the
jet
versus
the
sort
of
the
other
state
that
is
maintained
in
the
options
object.
A
A
A
D
B
D
A
B
A
Oh
yeah
and
sorry
it's
coming
back
to
me
a
little
bit
now.
The
the
other
thing
was
that
in
omr,
which
bit,
which
includes
jit
builder
jet
builder,
already
introduced
a
dependency
on
python.
So
anywhere
you
would
use
omr
python,
sorry
anywhere,
you
would
use
jit
builder.
You
would
have
python
already
there.
So
from
an
infrastructure
perspective,
all
of
the
machines
that
were
building
omr
on
every
architecture
had
had
a
python
3
installed.
A
The
the
challenge
was
all
the
downstream
projects
and
using
j9
as
an
example,
all
the
open
j9
build
machines
needed
to
have
it
all.
The
internal
open,
j9
built
all
the
ibm
internal
and
open
j9
machines
needed
to
have
python
installed
and
all
the
adopted
jk
machines
needed
to
have
iphone
3
installed.
A
A
We
may
not
have
everything
installed
properly
on
aix
and
there
may
not
be
everything
installed
properly
on
windows,
and
perhaps
you
know
a
few
other
variations
as
well.
So
I
think
the
whole
python
dependency
thing
is
a
separate.
We
can
almost
separate
that
from
from
this
kind
of
design,
because,
like
I
said
there
are
other
uses
of
python
that
that
could
be
explored,
and
I
don't
necessarily
want
to
tie
it
to
one
particular
one
particular
design.
There
are.
A
C
Yeah,
I
remember
looking
once
for
a
good
json,
open
source
library
that
was
written
in
c
or
c
plus
plus,
and
I
couldn't
find
anything
that
was
written
in
there
were.
There
were
good
libraries,
but
they
tended
to
use
more
modern,
c-plus
plus
that
wouldn't
have
worked
as
well.
For
us,
it
would
have
had
the
same.
It
would
have
brought
in
the
same
kind
of
problems
in
that
you'd
need
to
build
chains
to
be
able
to
support,
doing
the
build
which
wouldn't
have
made
sense
either.
A
Yeah
we
wanted
to
use
fairly
common
tools
and
technologies
in
order
to
build
this,
and
you
know
json
and
python-
are
you
know
actually
quite
common
in
in
ci
cd
pipelines
these
days?
So
it's
not
me.
It's
the
opinion.
It's
not
real.
It's
not
an
unreasonable
ask
to
suggest
iphone
being
part
of
that.
So
it's
just
a
matter
of
perhaps
highlighting
the
benefits.
C
B
C
C
A
A
So
in
terms
of
next
steps-
I
don't
know-
I
mean
philippines,
I
guess
you're
free
to
make
some
changes
to
options
as
as
you
as
you
think
you
you
need
in
order
to
do
that,
separation
nazim,
I
don't
know
if
there's
anything
that
you
have
already
done
from
the
other
pr.
That
is
reusable
for
that
effort.
A
A
The
other
thing
about
touching
this
kind
of
code
is,
you
have
to
be
super
careful
about
the
effects
of
it.
I
remember,
as
he
was
debugging
his
work,
that
there
were
instances
where
what
he
was
changing
for
his
new
framework.
It
was
getting
a
different
result
than
what
the
current
implementation
had
and
he
had
to
get
creative
in
some
cases
to
debunk
these
sorts
of
differences.
A
B
I
did
set
up
a.
I
did
set
up
some
macros
where
basically
for
any
option
queries.
It
goes
through
a
macro
that
queries
both
the
old
implementation
in
the
implementation
and
then
compares
the
result.
That
was
that's
not
something
done
by
default.
It
was
something
like
options.
Debug
configuration
option
with
build
something
like
that.
B
So
yeah,
that's
one
way.
This
was
addressed
when
we
had
that
issue,
but
yeah.
There
were
a
lot
of
unexplained
results
that
I
observed
there,
but
I
yeah,
I
tried
to
you,
know,
trace
it
back
and
make
sure
that
the
new
options
get
updated
along
with
the
older
one
and
yeah
so
that
that
might
be
gonna
help
me
identify
the
options
that
get
flipped
around
in
different.
A
D
B
C
A
A
Okay,
so
if
there
is
anything
you
want
to
bring
up
there
is
that
pull
request
that
that
nazim
has
had
there,
for.
I
guess
it's
going
on
two
years
now
so
by
all
means
feel
free
to
add
some
comments
there,
if
you,
if
you'd
like,
but
I
think
that
this
is
going
to
be
moving
forward.
But
just
given
the
priority
of
of
that
and
other
things,
it's
just
going
to
be
moving
at
a
little
bit
of
a
slower
rate
than
other
things.
A
Okay,
that
was
the
last
topic
we
had
on
the
agenda
for
this
week.
So
we'll
talk
again
in
two
weeks.
I've
already
created
the
proposed
agenda
for
for
that.
So,
if
you
have
any
topics
by
all
means,
please
add
them
there.
I've
already
propagated
the
linkage,
one
from
that
we
deferred
from
this
week
to
that
to
that
one.
So
you
can
pick
that
discussion
up
then
with
yann.