►
From YouTube: 2022-05-16 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
A
A
Probably
we
should
check
in
on
the
jonathan's
spec
pr
discuss
the
latest.
A
Some
interesting
some
turns
of
events.
A
So
I
think
we
kind
of
got
past
and
what's
interesting.
Actually,
I
my
understanding
of
bogdan's
comments
is
that
we
can
use
the
process
and
system
we
can
emit
process
and
system
metrics
from
jvm
instrumentation,
so
as
opposed
to
those
being
reserved
for
the
collector,
which
is.
A
A
Like
system,
I
thought
there
was
some
language.
B
A
A
Okay,
so
there
was
also
this
issue.
A
About
where
we
had
gotten
blocked
earlier
on
emitting
process,
cpu
time,
and
so
my
reading
from
bogdan-
is
that
he's
that
we
can
do
this
now?
I
think
we
just
need
to
codify
that
in
the
spec
get
other
sign
offs.
C
But
what
does
this
mean
like?
Can
we
I
can
keep
the
current
naming,
or
should
we
rename
things.
A
Think
that
it
helps
this
pr,
because
the
cpu
utilizations
in
this
pr
don't
match
the
definition
of
the
system.
Cpu
utilization,
because
it's
not
over
the
time
interval.
A
C
Yeah,
but
so
that's
what
I'm
I'm
saying
like.
Let's
say
that
you
are
running
in
a
container
and
you
have
only
one
core.
So
in
that
case,
what
each
avm
reports,
if
you
like
one
hundred
percent
like
occupy
that
core
instead
the
cpu
utilization,
is,
I
don't
know
like
one
hundred
percent.
C
C
A
C
D
A
A
A
Yeah,
I
think
I
had
put
in
a
update
fraction
of
its
usage
out
of
its
limit.
Our
utilization
values
are
in
the
range
zero
to
one.
A
So
yeah,
so
I
I
kind
of
left
the
open
question
here.
I'm
not,
I
guess
my
preference
would
be
to
not
would
be
to
continue
with
this.
The
this
pr
as
is,
and
not
try
to
stuff
these
metrics
into
something
that
doesn't
match.
A
A
So
I
had
sent
a
bunch
of
failed
prs
to
try
to.
A
That
process
was
that
process
that
utilization
and
time.
A
Were
the
two
that
were
important,
so
I
guess
but
jonathan
I
know
like
you,
have
you've
expressed
interest
in
having
the
the
cpu
core
count.
Independent
of
this
utilization
number.
C
Yes,
because,
like
the
utilization
is
basically
like
how
much
do
I
use
it,
and
if
it
is
so,
I
I
am
not
sure
like
how
can
I
get
that
so,
basically,
the
call
count
from
from
those
two,
because
I'm
not
hundred
percent
sure
you'll
be
able
to
get
it.
A
Yeah
I
mean
it's
a
little
odd
right,
but
I
mean
essentially
time
the
cpu
time
times
times.
The
utilization
was
it's
like
300,
divided
by
utilization.
C
So
the
utilization
is
basically
a
number
between
zero
and
one
right.
It's
basically
can
be
converted
easily
to
a
percentage,
and
the
time
is
how
much
like
time
the
cpu
did
utilize
since
the
process
started.
A
D
I
don't
think
you
can,
just
I
don't
think
that'll
do
that.
Will
it
because
you
can't
you
can't
tell
the
difference
between
using
300
could
mean
that
you're
using
three
cores
on
a
four
core
machine
or
it
could
mean
three
cores?
Oh,
I
see
what
you're
saying
I
think
I
got
there.
D
C
I
think
so,
although
this
is
so,
we
have
this
severe
utilization
and
the
cpu
time
both
reported
by
the
jvm.
C
C
Are
we
sure
that
this
will
always
work,
because
the
the
jvm
can
tell
you
the
core
count,
and
I
believe
that
is
a
very,
very
important
like
number
that
you
might
want
to
see,
especially
in
dockerized
environments,
but
we
can
we
can
get
that
into
another
pr.
I
I
am
totally
fine
with
that.
We
can
talk
about
that.
There.
A
A
C
Yes,
okay,
jmx
synthetic
is
the
original
way.
Okay,
I'm
not
sure
about
how
to
do
it
in
jfr,
but
it's
it's.
Actually
it's
not
even
jmx,
I
would
say
so.
It's
the.
E
A
A
All
right,
yeah
and
amazingly,
I
I
had
run
an
experiment
where
you
changed.
The
cpu
count
at
runtime
via
containers,
and
this
gets
updated
dynamically
at
runtime,
which
is
impressive
or.
D
Yeah,
that
is
surprising,
because
then
I'm
assuming
that
the
gc
algorithm
was
chosen,
doesn't
apply.
D
Be
awesome,
you
could
encounter
a
situation
where
it
chose
the
single,
the
single
core
collector
whatever,
when
drawing
a
blank
on
the
name,
a
sequential
collector.
C
A
A
A
All
right!
Well,
since
I
have
had
good
luck
engaging
bogdan
lately,
I
will
reply
and.
A
A
How
many
times
can
I
navigate
through
this
same
hierarchy?
Runtime
event,
okay,.
A
D
A
There's
just
an
asymmetry
to
them,
because
loaded
is
number
of
currently
loaded
while
unloaded
is
number
unloaded
since
the
start
of
the
jvm
got
it
yeah.
Now,
I'm
remembering.
B
D
D
A
E
And
I
I
think
if
I
remember
that
the
jmx
being
her
class
has
a
has
an
accessor
for
the
total
loaded
over
the
application.
E
A
Could
be
seems
to
me,
like
I
agree
like
it,
should
be
a
counter
any
arguments,
any
thoughts
on
why
it
should
not
be
a
counter.
E
For
symmetry,
so
if
you
have
it
as
a
counter-
and
we
have
this-
the
the
loaded
variant,
which
is
which
is
an
up
down
counter
out
of
necessity,
then
on
export
up
down
counters
up
down
counters,
always
have
cumulative
temporality,
and
so
you'll
you'll
have
like
the
the
current
number
of
classes
that
have
been
loaded.
But
then
the
unloaded
would
be
like
the
diff
to
a
delta
back
end,
and
so
you'd
have
kind
of
asymmetry.
D
E
D
Not
not
compared
to
unloaded,
I
don't,
but
I
think
the
total
loaded
over
time
is
an
interesting
number.
It's
not
a
delta.
Are
you
talking
like
time,
delta.
A
E
I
think
I
I
could
imagine
you
wanted
both.
I
agree
that
the
cumulative
is
generally
more
useful.
E
You
can
always
set
up
a
view
that
that,
like
you
know
that
took
the
loaded
class
count
and
let's
say
it's
a
counter
and
and
so
you're
going
to
get
the
delta
you're
going
to
get
the
diff
of
how
many
classes
were
were
loaded
in
that
period
of
time.
But
you
could
add
a
view
that
additionally
exported
it
as
a
gauge,
and
so
you
you
would
always
have
the
cumulative
count.
E
E
Yeah-
and
so
I
guess,
like
you
know
in
given
that
the
metrics,
the
fundamental
values
that
are
being
reported,
aren't
like
symmetric,
we
can
at
least
make
the
ex
the
experience
in
delta
back
ends,
similar
in
the
sense
that
you
know
both
will
receive
cumulative
values
instead
of
one
being
delta
and
one
being
cumulative.
So
it
kind
of
makes
it
a
little
bit
more
palatable.
C
That
how
would
you
would
you
measure
this?
It's
more
like
a
gauge,
because
it's
not
like
the
jbl
will
notify
you
every
time
when
something
is
unloaded,
so
you
can
like
increment
the
counter
and
count
it.
It
is
something
of
value
that
you
will
observe
that
the
jvm
will
provide
you,
and
that
is
a
little
bit
more
like
a
gauge
to
me.
E
Yeah,
the
difference
between
gauges
and
up
down
counters
and
open
telemetry
is
is,
is
really
nuanced
and
the
the
main
differentiator
that
that
I'm
aware
of
is
that
the
up
down
counters
are
supposed
to
be
aggregateable
across
their
their
attributes
and
gauges
aren't
and
this
one.
This
is
an
interesting
case
because
this
data
could
be
aggregated
across
dimensions
if
there
were
dimensions,
but
there
are
no
dimensions.
So
there's
no
attributes
so
like
that
property
doesn't
really
like
apply
here.
A
What
about,
I
think
jonathan
was
also
getting
that
the
counter
if
we
modeled
it
as
a
counter,
do
counters
only
take
like
increments,
or
can
you
reset
the
value
right?
Because
then
we
we
read
from
the
jvm,
the
jmx
being
we
get
a
total
value.
E
Yeah,
it's
a
it's
an
asynchronous
instrument
and
so
asynchronous
instruments
for
counters.
We
assume
that
we
are
observing
a
sum.
Not
the
increment
got
it.
A
E
I
I
don't
know
of
any
general
guidance.
I
know
that,
there's
a
conversation
in
the
pr
where
this
was
merged,
where
josh
mcdonald
was
having
this.
You
know
talking
about
this
exact
thing,
so
you
know.
E
Do
we
use
the
knowledge
that
this
is
this
metric
is
better,
is
more
usefully
analyzed
in
its
cumulative
form
as
a
reason
to
use
an
up
down
counter
for
something
that
is
like
technically
could
be
satisfy
the
criteria
of
a
counter,
so
that
yeah
this
this
exact
conversation
here
is
talking
about
that
and
I
don't
think,
there's
a
a
lot
of
situations
where
this
has
come
up
yet,
but
I
don't
think
this
will
be
the
last.
E
And
I
guess
this-
the
same
type
of
question
applies
to
this
idea
of
like
an
up
down
counter
versus
a
gauge.
So
you
know
we
could
model
these
as
gauges
and
it
wouldn't
make
any
material
difference
to
any
consumers
because
they
don't
have
attributes,
and
so
the
fact
that
gauges
can't
be
aggregated
across
their
attributes
doesn't
matter.
A
Right,
I
think
that
that
to
me
is
an
easier
one,
because
we
are
counting
things
right.
We
are
counting
classes
that
were
loaded
or
unloaded,
as
opposed
to
make
sense
to
me
up
down
counter
versus
gauge.
D
So
the
idea
being
you
take
the
total
number
of
classes
that
you've
loaded
and
the
total
number
of
classes
that
you've
unloaded
and
there's
your
resume
account
right,
but
those
two
things
have
to
be
in
in
lockstep,
though,
for
that
to
happen,
right
like
they
have
to
the
timings
on
those
have
to
happen
at
the
same
time,
and
I
think
a
consumer
of
that
doesn't
have
a
strong
way.
I
don't
know
of
a
strong
way
to
to
know
that
those
were
taken
at
the
same
time
right.
E
Well
so
they're
a
consumer
of
those
that
they
were
taken
at
the
same
time.
So
these
are
both
asynchronous
instruments.
We're
gonna
observe
these
things
happening,
and
so
we
register
a
call,
a
callback
which
reads
the
values
from
jmx
and
reports
them.
And
so
you
know
we
have
two
different
values,
so
we
register
two
callbacks
and
when
metrics
are
collected,
those
callbacks
are
are
are
invoked,
but
they're
not
done
like
atomically.
E
So
batch
callbacks
fix
that
to
some
extent,
because
you
know
you
stop
having
multiple
callbacks
registered
and
you
just
have
a
single
callback
that
can
record
to
multiple
values.
But
I
guess
technically,
like
you
know,
you're
still
making
two
different
calls
to
the
jmx
bean,
so
that
can
be
really
exactly.
D
D
E
So
we
could
have
a
a
loaded
and
an
unloaded
that
reflect
the
the
total
loaded
and
unloaded
since
the
start
of
the
jvm,
and
then
we
could
have
a
current
loaded
which
reflects
right
now,
yeah
and
then
so
you
know
the
loaded
and
unloaded
could
both
just
be
counters,
which
reflect
you
know
it's
the
most
correct
instrument
type
to
use
for
that,
and
the
current
loaded
could
be
an
up
down
counter.
So
you
know
that
would
restore
symmetry
and.
D
E
D
Yeah,
but
I
mean
that
could
also
be
a.
I
mean
this
isn't
a
metric
spec
discussion
at
this
point,
but
it's
like
you
could
imply
that
the
lack
of
any
updates
means
it
hasn't
changed.
D
B
B
E
E
Yeah
just
to
further
that
thought
a
bit,
so
asynchronous
instruments
can
be
unregistered,
so
their
callbacks
can
stop
reporting,
and
then
you
know,
even
if
they're
not
unregistered
the
other
thing
and
this
kind
of
goes
off.
What
what
fabian
was
saying
is
that
if
an
asynchronous
instrument
stops
reporting
a
value
for
a
particular
set
of
attributes,
it
is
no
longer
exported.
So
there's
this
I
this
idea
that,
like
asynchronous
instruments
manage
their
own
state-
and
you
know
if
they
stop
reporting
for
a
particular
set
of
attributes.
D
E
Going
back
to
this
this
proposal,
though,
of
loaded
and
unloaded
as
counters
and
current
loaded
as
up
down
counter
so
the
I
think
this
is
actually
a
pretty
good
outcome
task,
even
for
delta
back
ends,
because
delta
backends
can
still
like
know
about
the
like.
The
current
number
of
loaded
classes,
because
up
down
counters
are
always
exported
in
cumulative
format,
and
so
you
know
what
they
don't.
A
Yeah
yeah,
because
the
all
the
like,
the
charts
that
you
usually
see
of
is
the
total
currently
loaded
because
you're
looking
to
see
if
that's
just
going
up
and
up
and
up
and
up.
A
E
Awesome
thanks
jack
because
I
was
actually
thinking
about
opening
a
pr
to
the
open,
telemetry
java
instrumentation
to
add
this
instrumentation,
because
I
think
right
now
the
only
place
it
comes
from
is
the
the
jmx
collector
thing
in
contrib.
That's!
But
you
know,
it'd
be
nice
to
have
this
produced
from
the
agent
as
well.
So
that's
on
my
to-do
list,
so
I
can
just
update
the
spec
while
I'm
at
it.
That
would
be
awesome.
We
would
like
that.
A
All
right,
I
think,
that's
pretty
good
outcome
for
today.
Unless
people
want
to,
I
mean
we
have
the
gc
stuff,
but
we
need
somebody
who
has
time
really
to
probably
drive
that
at
this
point.
E
Last
we
heard
he
was
busy
he's
busy
with
his
this
book
that
he's
working
on
revisions
to
his
book,
and
so
I
think
he
mentioned
that
that
is
kind
of
wrapping
up
to
some
extent
and
he
hopes
to
have
more
availability
to
return.
His
focus
to
this.
But.
B
A
Yeah
and
if
we
run
out
of
things
once
we
run
out
of
things,
then
we'll
we
can
use
this
meeting
to.
Maybe
the
next
meeting
to
start
chatting
about
gc.