►
From YouTube: OMR Architecture Meeting 20220804
Description
Agenda:
* JIT scratch memory profiling [ @jdmpapin ]
A
B
B
Okay,
everybody
see
that
yes,
okay
great
now,
so
I
don't
have
any
slides.
So
I'm
just
gonna
sort
of
talk
about
it
and
then
show
show
what
what
I
have
so
the
the
context
here
is.
I've
been
trying
to
look
into
some
very
expensive
compilations,
both
in
expensive
and
compile
time
and
in
scratch,
memory
usage
and
some
of
the
scratch
memory
usage
is
just
it's
through
the
chart
or
off
the
charts
so
through
the
roof.
So
we
do
have
some
existing
stuff.
B
B
B
B
B
B
B
So
you
know
you
allocate
an
object
and
that's
this
many
bytes
and
whatever,
and
then
that
gets
it
gets
counted
and
then
now,
instead
of
recording
every
single
allocation,
I
treat
all
of
the
other
events
as
sort
of
significant
points
in
time,
and
I
just
sort
of
total
the
allocations
in
between
them
and
it's
a
there'll
be
like
sort
of
a
linear
approximation
between
the
significant
events
later
on.
So
then
this
event
stream.
A
A
B
B
B
Right,
okay,
so
I'm
going
to
be
using
java
here,
but
basically
none
of
this
is
java.
Specific.
The
the
implementation
is
almost
entirely
an
omr.
I
think
I've
got
some
something
about
the
getting
the
time
stamp
where
we
want
to
use
the
omr
port
lib,
which
we
can't
rely
on
being
able
to
directly
call
from
the
jit
at
the
moment
in
omr
code,
but
we
can
in
a
downstream
project,
and
so
I'm
sort
of
doing
an
end
run
around
that.
B
B
B
Here
we've
created
an
output
file
like
this.
Now
before
I
go
on,
I'm
just
gonna
delete
that
and
generate
a
new
one.
I
want
to
sort
of
highlight
this:
is
each
compilation
generating
this
stream
of
events,
so
each
one
naturally
has
its
own
output
suffix
logs
now
too,
so
that
we
don't
have
to
deal
with
all
the
junk
on
the
end
of
that.
B
B
So
sometimes
you
might
have
a
case
where
the
you
know
the
the
process.
You
know
it
didn't
shut
down
in
the
normal
way
right.
Something
like
this
happens
where
I
just
canceled
it
or
I
know,
we've
had
at
least
one
benchmark
that
we
cared
to
look
at
before,
which
ended
with
the
the
process
being
just
sent
a
sig
kill
for
some
reason.
B
B
B
B
B
B
B
B
B
This
is
the
peak
backing
memory
usage
for
scratch
memory,
it's
the
total
amount
of
time
that
it
took
and
the
op
level
and
the
signature,
and
these
are
sorted
by
scratch-
memory
usage.
So
if
you
look
at
the
memory
usage
here,
it's
increasing
the
time
is
not
increasing.
You
see,
it
goes
back
and
forth,
but
you
can
just
type
in
time
and
you
get
them
sorted
the
other
way.
So
now
the
time
is
increasing
here
and
the
memory
usage
see
this
one
used
less
memory
than
that.
B
A
A
B
So
instruction
selection
happened
nested
within
the
cogen
scope,
dynamically
nested.
Anyway,
it's
not
a
lexical
thing,
if
that
makes
sense
right,
it's
sort
of
like
it's
like
an
activation
frame
for
a
function,
but
it's
it's
this
scope
instead,
so
it's
sort
of
you
can
see
the
stack
right.
We
were
compiling,
we
did
cogen,
we
did
instruction
selection
and
you
know
you
can
see
how
much
time
we
spent
you
know
the
instruction
selection
was
16
and
a
half
milliseconds
these
percentages.
B
B
B
You
can
also,
you
know,
say
here's
inlining,
and
this
is
ilgen
and
you
say:
okay
well,
what
were
we
really
measuring
when?
Oh,
you
know
what
that's
not
going
to
it's
not
going
to
show
up.
I'd
have
to
switch
windows
again
anyway,
so
it
tells
you
where
the
where
the
thing
is,
and
you
can
there's
a
there's
a
hook,
so
you
can
right
click
on
this
and
it'll
open
it
in
in
your
editor.
If
you
have
a
script
to
to
do
that
from
the
file
and
line
number.
B
B
B
B
Okay,
then
you
know
the
the
star
of
the
show
here
is
the
memory.
So
this
is
scratch
memory
usage
over
time,
so
you
can
see
these
linear
approximations
here
right.
You
can
end
up
with
this
straight
line,
and
it's
just
that
you
know
there
wasn't
necessarily
any
interesting
events
along
there
anyway.
This
is
you
know
how
much
memory
we're
using
over
time
and
it
measures
well
it.
B
B
The
orange
then
is
the
node
pool
region
and
then
cfg
regions,
structure,
regions,
alias
regions
and
so
on,
and
then
at
the
top
we
have.
This
yellow
is
the
stack
regions,
which
is
a
mostly
stacked
memory
region,
but
it
also
includes
some
that
that
are
not
registered
as
a
stack
memory
region,
but
declared
on
the
stack
for
a
relatively
short
time,
which
happens
in
a
few
places,
and
so
in
here
we
can
see.
You
know
I
mean
this
right
here
is
clearly
where
our
peak
memory
usage
is
right.
B
B
B
B
A
B
B
B
A
B
Okay,
so
so
those
are
the
three
kinds
of
memory
that
we've
measured
and
so
I'll
go
back
to
requested.
So
when
you
look
at
requested,
it
shows
the
gray
is
sort
of
the
top
of
where,
where
the
allocated
memory
would
be,
and
the
the
pink
or
the
sort
of
transparent
red
is
where
the
backing
memory
reaches
up
to
all
right.
So
what
we
could
do
with
this
now,
so
you
can
zoom.
B
You
know,
and
you
can
look
very
closely
if
you
want-
and
this
x-axis
is
tied
to
the
to
the
timeline,
so
you
can
see
what
part
of
you
know
what
you
were
doing
at
the
part
on
the
graph
that
you're
looking
at,
but
probably
more.
Interestingly,
we
can
select
a
range
of
time
like
that
and
it
will
identify
the
peak
memory
usage
within
the
selected
range
or
you
can
sort
of
double-click
to
select
the
whole
thing,
and
so
here's
our
peak
memory
usage
right.
B
B
B
B
B
Now
from
here,
we
can
go
into
the
memory
flame
graph,
so
this
is
just
like
the
time
flame
graph,
but
but
now,
instead
of
the
width
of
these
frames
representing
an
amount
of
time,
they
represent
an
amount
of
memory,
and
this
is
just
memory.
It's
it's
who
allocated
the
memory
that
is
still
outstanding
at
this
exact
moment,
which
is
exactly
what
you
need
to
know.
If,
if
you
want
to
be
using
less
memory
at
this
at
this
peak.
B
And
yeah,
so
we
could
see
you
know,
for
example,
right
like
we
out
here.
We
can
see
that
it's
the
stack
memory
that
suddenly
increased
the
most
right,
there's
a
bit
of
of
alias
or
whatever.
So
you
can
look
at
say
just
stack,
that's
that
category
and
we
see
that
it's
almost
entirely
partial
redundancy
elimination
doing
that
and
now,
if
you
were
to,
you,
know,
put
some
some
of
those.
B
And
of
course,
that
that
flame
graph
is
using
the
the
measure
here
of
requested
memory,
but
if
you
were
in
you
know
allocated
say,
then
it
would
show
you
allocated
right.
So
this
is
85.8
megs,
which
is
the
total
selected
here,
which
is
different
from
the
83
requested.
So
that's
not
too
much
overhead
over
here.
B
B
B
B
B
That's
just
sort
of
to
give
you
an
idea
of
kind
of
the
resolution
of
the
the
time
data
that
this
thing
is
working
with.
So
if
it
if
it
gets
too
too
precise,
you
know
you
know
like
if,
if
you
see
things
that
look
like
they're
one
nanosecond,
you
know
that's
that's
a
fiction
where
it's
it's
sort
of
spread
things
out
in
between
in
between
successive
timestamps
and
then
all
of
this
stuff
down
here
is
just
sizes
of
parts
of
the
the
temporary
file.
B
B
B
B
I
was
seeing
a
larger
problem
with
alias
memory
before
I'm
not
sure
what's
going
on,
but
here
we
can
see
like
this
just
absurd
number
of
regions.
Again
this
is
122
000
regions,
and
now
I'm
not
going
to
go
into
the
flame
graph
for
this,
because
it's
it's
slow
and
it's
slow
because
of
there's
just
this
number
of
regions
is
just
crazy
and
they're,
basically
all
cfg
and
structural
regions,
so
there's
definitely
something
going
on
there.
B
B
B
B
B
A
B
B
B
B
B
You
know
one
hot
compilation,
log.
If,
if
it's
a
big
enough
method,
so
I
tried
really
hard
to
keep
the
the
output
compact,
but
anyway
there
there
you
have
it
here,
there's
there's
more
detail
on
on
what's
happening
during
inlining
in
this
one.
You
can
collapse
this
recursion.
When
you
look
at
the
flame
graph.
B
A
A
To
find
where
some
of
these
memory
allocation
problems
are
and
you've
identified
a
few
places,
you
know
you
didn't
mention
them
all
on
this
call,
but
I
think
that
it's
really
proven
its
value
there.
So
you
know
getting
this
into
the
code
and
getting
it
into
the
hands
of
other
developers.
I
think,
would
be
a
very
useful
tool
to
have
for
sure.
A
Very
early
on
you
were
talking
about
lexical
memory,
profiling
and
lexical
timers,
like
we
already
have
functions
for
that.
Are
you
saying
that
we
could
deprecate
those
and
perhaps
unify
all
this
under
under
these?
I
don't
know
what
you
want
to
call
them
tags
that
you
would
add
in
the
code
to
delimit
where
this
profiling
should
occur.
B
B
A
A
I
can't
remember
that
term
is
where,
where
the
memory
is
going
to
be
like
who's
asking
for
the
memory,
you
know
at
least
like
15
years
or
so
ago,
but
I
think
that
that
has
definitely
not
been
enforced
as
much
as
it
used
to
be.
So
I
think
a
lot
of
it
is
stale,
but
the
reason
I'm
asking
that
is
because
perhaps
with
an
perhaps
all
of
that
infrastructure
for
that
could
be
deprecated
as
well
with
the
proper
placement
of
these
profiling
books
or
tags.
A
B
Yeah
that
definitely
makes
sense
for
persistent
memory.
I
think
because
this
all
this
stuff
that
I've
just
shown
is
completely
based
on
on
region
in
in
scratch,
scratch
memory
and
by
the
way
it
relies
on
on
the
compilation
not
leaking
any
memory
at
a
lower
level
than
region
which
we
currently
have
a
central
memory
leak
in
in
open
j9.
B
A
B
A
Don't
think
I've
used
them
before
yeah
there's
a
it
may
actually
be
a
debug.
You
have
to
enable
it
under
debug
like
a
like
they're
guarded
with
the
debug
macros.
So
it's
been
a
long
time
since
I've
used
them
and
I
wouldn't
even
rely
on
them
anymore,
because
I
think
that
they
are
very
stale.
I
don't
think
that
people
have
been
maintaining
them.
B
B
B
B
B
B
A
No,
it's
yeah,
I'm
very
glad
to
see
that
you
know
we
have
something
like
this
developing
it's
memory.
Consumption
is
something
we
really
haven't
kept
an
eye
on
for
a
long
long
time
in
the
jet
I
mean
there
have
been
other.
I
mean
there
have
been
cases
where
yes,
we've
had
to,
but
tracking
it
at
this
level.
I
don't
think
we've
done
in
in
quite
some
time.
So
it's
a
great
great
step
forward
here.