►
From YouTube: 2022-05-02 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).
A
B
B
I
was
realizing
this
morning
when
I
put
this
shirt
on
that
oscar
will
never
be
a
thing
anymore,
since
o'reilly
killed
all
conferences
like
it's
kind
of
a
bummer
2019.
I
guess
last
one
who
knew.
A
B
C
He
didn't
mention
anything
on
thursday,
so
I
would
anticipate
him
coming,
but.
D
Yeah,
I
know
so
yeah
I
yeah,
I'm
sorry.
I
was
late,
I
that
am
for
my
my
newly
moved
in
neighbor.
He
was
just
having
a
doing
a
lot
of
travel
at
the
moment
and
so
asked
if
she
could
have
some
parcels
delivered
here.
I
wasn't
expecting
part
of
a
three-piece
suite,
which
is
what
was
just
turning
up
as
the
call
was
trying
to
start
and
I
was
trying
to
get
online
and
I'm
like.
There
are
two
dudes
here
who
who
are
bringing
basically
half
of
a
sofa
into
my
house.
I'm
just
like.
D
D
Anyhow,
you
know
so
yeah
so
last
week
fabian
was,
and
I
were
were
on
the
call
and
we
we
basically
we
we're
just,
I
think,
waiting
for
the
official
1.0
to
drop
before
we
can.
We
can
do
stuff.
D
I
haven't
had
a
lot
of
time
to
work
on
this
because
I've
been
finishing
my
book
and
that
is
still
you
know
there
all
there
abouts.
So
I
think
I
think
hopefully
this
week
things
should
clear
up
a
bit,
but
I've
been
saying
that
for
a
couple
of
weeks
now
but
never
mind.
D
C
C
Yeah
so
there's
a
couple
parts
that
I
guess
are
part
of
it.
So
there's
exemplars,
so
that's
not
going
to
be
in
the
initial
stable
release
and
that's
because
they're
not
stable
at
the
spec
level
and
then
the
prometheus
exporter
isn't
stable
at
the
spec
level
either.
So
I
think
those
are
the
two
omissions.
C
Then,
are
you,
are
you
making
any
effort
or
progress
around
the
trying
to
find
a
common
ground
between
the
different
garbage
collectors.
D
Yes,
I
have
some
numbers
that
I've
come
up
with,
but
they
rely
upon
having
access
to
the
event
data.
So
I'm
just
I'm
still
thinking
about
what
how
to
do
that
for
for
jmx,
because
the
the
jmx
scraper
doesn't
doesn't
have
knowledge
of
the
actual
events.
D
D
I'm
I'm
having
a
proper
think
about
it,
because
I'm
sure
that
you
know,
I
can't
believe
that
that's
the
case,
there
must
be
something
you
can
do,
but
what
I'm
I'm
dimly
remembering
is
that
from
my
j
clarity
days,
this
was
a
problem
that
we
encountered
as
well
that
basically,
for
certain
things
to
get
actually
accurate
information.
You
needed
to
look
directly
at
the
logs,
because
the
logs
were
event
driven
rather
than
rather
than
just
periodic
refresh,
and
that
there
are
fewer
data
points.
D
There
are
just
fewer
data
points
that
you
can
get
out
of
the
the
jmx
data
versus
logs
or
actual
events.
So
that
would
be
unfortunate
if
we,
if
we
got
to
this
point
and
then
discovered
that,
but
it
might
be
the
case
I
haven't
had
you
know.
In
truth,
I
haven't
had
enough
mental
bandwidth
to
look
at
it
in
detail.
C
Also,
I
don't
have
any
updates
regarding
other
jvm
runtime
metrics
conversations.
Does
anyone
have
anything
else
they
want
to
talk
about.
B
D
I
think
the
answer
is
no,
but
I
think
that
it
provides
a
different
spanning
set
basically
allows
you
to
get
to
all
the
other
observables.
So,
for
example,
if
you
switch
on
things
like
the
tenuring
distribution
events,
you
can
get
the
same
as
the
as
the
gc
logs
tenuring
distribution,
and
that's.
That
is
interesting
because
it
enables
you
to
work
out
some
second
order,
stuff
which
you
can't
get
to
otherwise.
D
Okay,
so
yeah,
I
didn't
have
anything
else
that
I
specifically
wanted
to
talk
about.
I'm
I'm
just
trying
to
get
my
decks
clear
enough
in
order
to
in
order
to
actually
work
through
some
of
the
backlog
like
rebasing,
my
patch,
and
seeing
what
I've
actually
got
and
what
the
altruism,
what
else
I
want
to
add
into
it
before
before
declaring
the
patch
ready
to
be
merged.
B
Do
we
have
kind
of
a
next
category
of
jvm,
metrics
kind
of
in
the
pipeline
after
gcm
memory.
D
Yeah
threads,
because
the
thread
count
is
something
that
I
don't
think
we
can
get
very
easily
from
jfr.
It
is
present
in
jmx,
but
that
would
imply
that
if
you
were,
if
you
were
deploying
a
jfr
solution,
it
would
also
have
to
read
at
least
either
the
jmx
apis
or
whatever
supplies
the
jmx
apis.
In
order
to
tell
you
what
the
thread
counts
are.
So
if
someone
felt
the
need
to
to
or
had
the
time
to,
go
and
look
at
threads,
that
would
be
a
useful
thing.
A
D
E
I
believe
it
can
be
an
issue
in
one
particular
case.
I
believe
like
threat
counts
is
not
that
scenario,
but
like
jmx
is
sometimes
problematic.
If
you
are
building
a
native
image
like
it,
it
has
a
couple
of
like
things
that
are
missing
right
now
on.
If
you
are,
for
example,
using
a
gravia
native.
D
Yes,
but
at
the
moment
we
we're
extremely
limited
by
what
we
can
do
in
in
graveyard
anyway,
because
the
graveyard,
the
only
garbage
collector
present,
for
example
in
graviam,
is
cereal
and
serial
is
not
completely
instrumented
with
jfr
events.
D
Yeah-
and
this
is
an
open
standard,
so
we
can't
accomplish
that
so
so
yeah
so
you're
quite
correct.
Of
course.
Johnny
the
the
open
source
edition
only
has
cereal
in
it
and
that's
all
we
can
do
for
for
for
an
open
standard.
B
So
ben
you're
thinking
about
threads
as
the
next
kind
of
chunk
other
than
other
than
thread
count.
Do
you
have
other
aspects
that
you
think
are
included?
Do
we
have
those
written
down
anywhere.
D
I
don't
think
that
they've
been
fleshed
out.
I
think
we've
got
some
notes
in
one
of
the
docs
okay,
so
if
you
can
find
that
and
then
the
class
is
loaded
and
unloaded,
it's
the
other
thing.
C
A
D
D
So
we
could,
for
example,
introduce
a
a
metric
which
had
tags
on
it,
which
say
total
in
this
60-second
time
block
these
thread
ids
or
these
thread
groups
or
these
thread
patterns
have
this
cumulative
time,
because
then
that
would
be
a
dimensional
metric,
but
the
problem
is:
is
that
that
is?
That's
got
to
be
an
optional
thing,
because
you
can't
do
that
from
jmx.
D
You
don't
you
just
don't
have
that
level
of
information.
So
this
is
why
what
I
want
to
do
is
I
want
to
finish
defining
what
the
core
of
this
is,
so
that
we
can
move
on
to
do
more
of
this
in
the
optional
pieces,
because
some
of
this
is
you
know
we
at
some
point.
We
will
finish
agreeing
what
the
common
core
is
and
then
the
two
implementations
have
to
define
what
they
can.
They
can
both
do
and
then
you
know
that
then
provides.
A
B
D
Because,
apart
from
anything
else,
that
that's
also
tangential
on
not
only
I
o,
but
also
on
on
locks,
because
one
of
the
ways
that
you
can
you
can
see
not
100
cpu
utilization
is,
by
a
very
high
thread,
context
switch
rate
because
it's
just
trying
to
get
a
lock
and
not
being
able
to
get
it
and
it.
Basically,
it
keeps
the
cpu
fully
utilized
by
just
swapping
things
in
and
out
endlessly
and
not
never
actually
getting
any
any
any
time
slice
to
any
useful
activity
and
are
some
of
those
locks
are
still
backed.
D
Well,
when
you
say
a
lock,
it
typically
means
an
os,
lock,
okay,
all
right,
because
a
spin
lock
will
busy
wait
and
that
will
burn
cpu
yeah
yeah.
But
you
know
to
your
point:
it's
that
that
raises
the
whole
question
of
how
those
things
perform
in
single
core
containers.
D
No
okay,
is
it?
Is
it
secret?
No,
not
at
all
it's
it's
the
second
edition
of
the
first
book
I
wrote
the
world.
B
D
Developer
so
it's
it
was
supposed
to
be
a
quick
update.
It's
supposed
to
contain
30
new
material
and
a
bit
about
you,
know
60
to
70
original
stuff.
D
D
So
it's
all
good
stuff.
It's
got
like
you,
know,
functional
programming
and
advanced
concurrency
and
internals
and
bytecode
and
stuff
in
it.
So
you
know
all
the
kind
of
stuff
that
I
like
to
talk
about.
Yeah
the
snarky.
B
Yeah,
I
don't
see
anything
right
off
related
to
jmx
and
context
switch
rate.