►
From YouTube: OMR Architecture Meeting 20220217
Description
Agenda:
* Compiler memory leak discussion [ @kevindean12 ]
A
Welcome
everyone
to
the
february
17th
omar
architecture
meeting.
Today
we
have
one
topic
and
it's
a
compiler
topic,
so
kevin
dean
will
be
talking
about
a
compiler
memory
leak
that
he
and
his
team
have
discovered
and
would
like
some
some
deeper
insights
on
so
I'll
turn
it
over
to
kevin
to
to
take
us
through
it.
C
B
Those
will
be
the
kind
of
the
relevant
ones
all
right.
So
let's
show
you
what
we've
what
we
encountered.
So
we
we
recently
changed
over
from
an
older
version
of
the
node
pool,
more
or
less
as
it
used
as
it
once
existed
in
the
omr
project
itself,
and
it
still
existed
for
up
till
recently
in
our
code
base
and
began
using
the
the
node
pool
that
is
found
in
omr.
B
Now
that
the
original
node
pool
that
we
were
switching
away
from
was
using
a
cs2
data
structure,
the
table
of
that
was
backed
by
a
tr
allocator.
We
still
see
some
of
these
floating
around
in
some
places,
but
for
the
most
part,
they're
kind
of
on
their
on
their
way
out.
I
think
they're
deprecated,
that
that
is
now
been
replaced
in
the
new
node
pool
with
a
with
a
tr
region.
B
B
You
know
out
of
memory
related
crashes,
so
we
so
we
started
investigating
this
and
ran
ran
our
some
small
kind
of
unit
tests
under
valgrind,
and
so
what
we
have
here
is
a
is
a
stack
trace
from
valgrind
that
is
kind
of
representative
of
a
bunch
of
similar
stack
traces
that
we
that
we
were
seeing
related
to
the
node
pool.
So
what
we're
looking
at
is
you
know?
B
First
beneath
this
there
would
be
some
front-end
kind
of
il-gen
code
that
results
in
the
creation
of
a
node
in
the
process
of
of
creating
that
node.
The
node
pool
is
asked
to
allocate
this
region
is
a
is
a
member
of
that
node
pool
which
we'll
look
at
in
a
little
more
detail
shortly
and
so
that
that
region
then
is
asked
to
allocate
segments
that,
then,
you
know
kind
of
follows
down
the
the
the
chain
of
the
of
the
segment
provider.
B
B
B
Okay,
so
the
node
pool
exists-
and
this
is
this-
is,
as
the
code
exists
in
in
omr,
so
the
node
pool
is
being
allocated
and
stored
as
a
as
a
pointer
in
the
compilation.
So
we
have
an
instance
of
the
compilation.
That's
that's
created,
and
eventually
you
know
it
will
go
out
of
scope
and
have
its
destructor
called.
B
B
We
have
this
compilation
nodes,
member
of
the
compilation
class
that
allocates
a
new
node
pool.
I
didn't
show
the
the
node
pool
constructor
here,
but
the
gist
of
it
is
that
so
the
node
pool
has
this.
This
region,
member
called
the
node
region
and
you'll
notice.
It's
not
a
it's,
not
a
reference
right.
B
B
So
useful,
maybe
to
as
kind
of
a
refresher
of
what
the
region
destructor
does.
So
when
the
region
has
allocated
allocated
segments,
it's
keeping
a
list
of
these
segments
that
it
that
it
owns
so
to
speak,
and
when
it,
when
the
region
is
destroyed
it
will
it
will
release
each
of
these
segments
in
turn,
so
it'll
walk
through
its
list
of
segments
and
ask
its
segment
provider
to
release
them
in
this
case.
B
What
that
means
is
this:
the
system
segment
provider
is
going
to
call
the
de-allocate
function
from
the
raw
allocator
and
that's
basically
a
wrapper
around
free,
so
those
maleks
that
we
saw
in
the
in
the
valgrind
stack
trace
when
a
region
goes
out
of
scope.
Normally
what
should
happen
is
those
are
those
have
a
corresponding
free
called
from
that
gets
called
eventually
from
this
destructor
call
from
the
region.
B
B
So
because
that's
the
case
when
the,
when
the
compilation
goes
out
of
scope
and
has
its
destructor
called
this,
here
is
what
the
compilation
destructor
looks
like
right:
it's
just
a
sort
of
a
default
constructor,
a
destructor
rather,
and
that
mean
what
that
means
right-
is
that
the
the
this
compilation
destructor
will,
by
its
default
behavior
called
the
destructors
of
any
of
its
non-pointer
members
of
the
compilation
class.
But
it's
not
gonna.
It's
not
gonna!
Do
that
for
pointer
members.
B
So,
as
a
result,
the
compilation
destructor
doesn't
call
the
the
node
pools
destructor
right.
What
happens
then,
of
course,
is
that
the
the
node
pool,
having
not
had
its
destructor
called,
doesn't
doesn't
call
the
destructor
of
its
of
its
node
region
so
that
that
region,
member
of
the
node
pool,
doesn't
get
it
never
has
a
destructor
called
so
the
memory
that
was
allocated
using
that
region
never
gets
cleaned
up,
which
leads
to
our
memory
leak.
B
Okay,
so
I'm
gonna
pause
here
I
I
do
have
so
we
can.
We
can
talk
more
about
the
the
cfg
case,
which
is
which
is
quite
similar
actually
in
in
terms
of
what
it
looks
like,
but
I
want
to
sort
of
stop
at
that
point
and
let
people
kind
of
jump
in
with
questions
or
other
other
kinds
of
discussion
related
to
this
right.
So
the.
B
B
Actually
do
anything
to
the
node
with
the
node
pools
destructor,
we
don't
have
to
write
any
any
any
explicit
destructor
for
the
node
pool.
It's
it's
default.
Compilation
compiler,
provided
destructor
will
do
that
we'll
we'll
do
what
we
need
it
to
do,
which
is
to
call
the
destructor
of
that
node
region
and
then,
as
we
as
we
saw
right
when
that,
when
that
node
regions
destructor
is
called
it
will,
it
will
free
up
the
memory
that
it
that
it
had
allocated
and
and
that
that
clears
up
the
memory
leak.
B
So
so
this
sort
of
provides
the
solution
to
at
least
as
far
as
our
front-end's
use
of
the
code
is
concerned
to
the
the
leak
come
that's
coming
from
the
node
pools
region.
So
to
the
question
that
is
sort
of
at
the
top
of
the
slide.
Should
the
solution
be
a
task
at
the
front?
You
know
the
corresponding
sort
of
question.
Is
that
right?
B
B
There
may
be
others,
but
these
are
the
ones
that
we've
that
we've
encountered
so
far
and
in
each
case,
so
here
you
know
that
we're
showing
this
code
at
the
omr
level,
omr
compilation,
but
of
course
the
this
isn't
what
exists
currently
in
the
omr
code.
So
this
would
either
have
to
be
implemented
at
the
omr
level
or
in
each
case
right.
A
project
extension
would
have
to
take
care
of
performing
these
destructor
calls
or
or
whatever
other
similar
solutions.
Someone
might
want
to
cope
with.
B
D
Hi
this
is
erwin,
so
the
the
the
way
this
whole
memory
infrastructure
was
designed,
I
think,
was
very
much
in
a
like.
I
think,
with
how
java
was
doing
things
yeah
and
so
the
the
idea
there
was
that
you
would
have.
You
know
these
little
compilations
of
the
different
methods
you're
trying
to
compile
dynamically,
and
so
the
way
it
worked
was
that
you
didn't
need
to
worry
about
destructing,
the
node
pool.
D
If
we
haven't
ever
used
it,
but
let's
just
say
we
did,
because
the
system
segment
provider
would
go
out
of
scope
at
the
end
of
what's
known
as
like
a
compilation
unit,
and
then
for
our
next
compilation.
Another
system
segment
provider
would
be
instantiated,
and
so
because
of
that,
when
the
system
segment
provider
went
out
of
scope,
it
would
free
all
the
segments
and
you
wouldn't
have
a
memory
leak,
and
I
mean
that
still
happens
in
walmart
too.
D
D
C
Sort
of
thing,
I
guess
my
my
intuition
is
that
for
things
that
are
about
as
long-lived
as
the
compilation,
it's
going
to
be
a
lot
less
error-prone
to
just
free
all
the
segments
at
the
end,
then
to
make
sure
oh
did
we
call
this
one?
Did
we
call
that
one?
Oh,
we
forgot
this
one
and
then
you
know
this
will
happen
again.
B
And
so
so,
in
that
context
we
have
the
the
the
system
segment
provider.
Basically,
the
the
expectation
is
that
that
the
system
segment
provider
is
doing
it
lasts
for
for
one
compilation
and
then
is
replaced
with
it
with
another
one
so
that
it's
the
memory
is
getting
freed
in
between
each
compilation.
C
A
We
had,
I
think
we
had
a
discussion
at
some
point,
perhaps
as
part
of
the
our
earlier
discussions
almost
a
couple
of
years
ago
now
on
refactoring,
some
of
the
memory
allocator
infrastructure
in
the
compiler,
where
we
really
wanted
to
favor
more
that
approach,
where
you
know
destructors
wouldn't
be,
we
wouldn't
be
reliant
on
destructors
being
running.
We
would
really
just
sweep
the
memory
away
when
we,
when
we
were
done
with
it.
So
I
think
that
was
the
model
that
we
had
decided
we
wanted
to
go
to.
A
So
I
I
agree
with
what
with
what
devin's
saying
here
with
with
that
being
the
preferred
approach
and
solution
in
this
in
this
case
now,
having
said
that,
though,
if
that
is
what
we
want
to
do,
I
think
that
we
we
need
some
big
fat
documentation
somewhere
that
really
describes
you
know.
This
is
how
it
should
be,
if
you're,
if
you're,
implementing
something
that's
consuming
the
compiler
technology-
and
you
know
this
is
how
your
your
memory
segment
should
behave.
Per
compilation.
A
B
Right,
yeah
yeah,
so
if
we
have
one
one
segment
provider
for
per
compilation,
you
know.
Interestingly,
I
think
I
I
had
I
toyed
around
with
that,
but
I
didn't.
I
didn't
know
at
the
time
that
that
was
you
know
how
things
were
handled
in
j9,
and
so
I
I
didn't
toy
around
with
it
enough,
probably
to
come
up
with
a
good
answer.
I
would
like
to
play
around
with
this
more
now,
knowing
that,
but
if
we
have,
if
we're
able
to
replace
the
system
segment
provider.
B
F
B
C
C
B
C
B
More
sense
because
I
was
thinking
to
myself,
you
know
I
swear
that
I
had
tried,
like
making
sure
I
got
rid
of
the
system
segment
provider
each
time
between
the
compilations,
because
of
course
that's
that's
at
the
bottom
of
kind
of
that
memory
stack
or
almost
all
the
way
at
the
bottom,
but
yeah
that
makes
that
makes
more
sense.
If
there's
something
specific
going
on
in
j9.
To
have
that
happen,
then
that's.
Why
that's
why
I
wouldn't
have
seen
it
seen
that
as
a
solution
right
away.
G
D
C
D
C
C
G
C
G
C
A
D
I
don't
think
you
can
just
lift
that
code
because
they're,
it's
quite
different
in
j9,
but
it
it's
gonna
have
to
be
like
omar's
gonna
have
to
have
his
own
version
of
it,
but
it's
it's
still.
I
think
what
devin
said
like
maybe
three
or
four
lines,
because
in
in
in
j9
the
the
art
like
the
way
these
things
are
composed
is
different
than
omar.
That's
one
of
the
reasons
we
had
that
proposed
memory
changes
is
to
keep
things
consistent
and
the
destructor.
A
B
B
F
B
F
It's
again
somewhat
similar
memory
leaks,
definitely
lost
from
the
background.
This
case
is
happened
when
we
call
call
the
is
actually
invoked
by
the
compiler
method
and
calling
to
perform
optimization
and
from
the
stack
trees.
We
see
it's
go
back
to
cursor,
then.
Finally,
some
to
the
raw
allocator
again
my
lock
and
we
find
out
that
the
memory
it's
totally
lost
never
can
free.
B
Sure
so
so
one
thing
I'll
point
out
here,
james
just
to
not
make
you
have
to
repeat
repeat
too
much
for
this
part
is,
is
like
this.
This
story
here,
basically,
is,
is
similar
right
about
the
this.
The
the
the
road
here
leads
back
to
a
region
in
the
cfg.
Basically
is
the
brown
is
the
is
the
memory
leak
story
here
which,
in
the
end
kind
of
looks
the
same
as
the
as
the
node
pool
situation
right?
B
So
this
there's
a
region
in
the
cfg
that's
being
used
to
allocate
in
in
this
case,
what
we
find
is
so
we
have
this
type
def
vector
of
subgraph
node
pointers,
that's
backed
by
what
turns
out,
in
the
end,
to
be
this
structure
region
from
the
cfg
and
for
the
same
reason
as
the
node
pool
causes
a
leak
right.
This.
B
This
will
end
up
having
a
leak,
because
the
cfg
is
stored
as
a
pointer
inside
of
the
res
resolved
method,
symbol
which
is
stored
as
a
pointer
inside
of
the
compilation
again,
one
thing
that
that
james
discovered,
though,
was-
and
I
think,
had
a
question
about-
was
related
to
not
just
that
memory
leak
per
se,
but
also
to
the
use
of
of
the
cursor.
More
generally,
I
think
is
that
true
james.
B
B
We
can
probably
handle
this
with
the
system
segment
provider
changes
that
we
that
we
discussed,
but
there's
also
the
james,
had
worked
on
a
sort
of
another
work
around
and,
I
think,
had
a
question
about
some
of
the
the
way
the
cursor
is
doing
a
a
copy
so
james,
I
can
I'll
give
it
back
to
you.
There.
F
Oh
yeah,
thank
you
yeah.
What
are
we
concerned
about?
It
says
the
cursor
is
actually
provide
a
immutable
view
of
the
underlying
elements
and
to
achieve
that
it,
the
cursor
itself
is
actually
must
copy
the
elements
from
the
sub-node
list
listed
before,
and
it
is
of
course,
in
none,
adding
a
non-trivial
cost
for
this
one.
F
F
Payments
and
check
the
results,
then
than
the
maverick
leaks
is
gone,
and
probably
we
can
save
some
additional
the
the
cost
of
the
copy.
And
but
the
thing
is,
this
is
experiment
experimental
test.
I
didn't
really
ensure
I'm
using
any
cloud
successor
to
ensure
the
elements
is
not
modified
or
whatever,
and
the
other
thing
is
we
have
to.
F
If
we
are
using
this
approach,
we
may
have
to
replace
the
cursor
or
get
rid
of
cursor
is
not
just
in
one
place
in
marketplaces
like
in
structure,
we
have
a
method,
initial
structure
and
there's
a
method.
I
think
it's
a
reset
structure,
something
like
that.
We
can
again
to
replace
the
cursor
and
a
few
other
places
possibly
to
use
this
approach.
F
F
C
C
And
then
you
know,
there's
also,
you
know,
maybe
we
want
to
just
you
know,
get
rid
of
some
of
these
things.
I've
been
trying
to
look
at
memory
usage
during
a
compilation
and
part
of
the
thing
is
that
tons
of
the
regions,
though,
that
we're
creating
and
some
of
the
methods
I'm
looking
at
are
well.
I.
C
C
F
F
B
F
B
Cleanup
to
the
omr
system
segment
provider
so
that
we
can,
you
know,
give
that
a
shot
and
see
if
that
that
takes
care
of
the
issue,
and
probably
we'll
have
to
do
some
adapting
on
our
end.
Also
to
make
sure
that
that
the
system
segment
provider
is,
you
know,
created
once
and
going
out
of
scope
for
each
compilation.
But.