►
From YouTube: Diagnostics WG meeting May 31 2022
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
So
welcome
to
the
node.js
diagnostic
working
group,
meeting
31st
may
2022
to
start
with
other
announcements.
A
B
Yep,
so
basically
what
it
was
just
to
the
first
we
had
a
discussion
to
say:
okay,
maybe
we
should
try
to.
I
did
it
in
the
list
and
then
we
we
decided
it
was
a
good
idea
to
do
it,
and
then
I
raised
another
pr
to
add
a
few
tests
just
to
test
the
integration
between
node
and
v8.
So
and
then
I
try
to
work
on
a
kind
of
guide,
about
memory
leaks
and
how
we
could
use
trace
dc
in
that
way,
something
that
I'd
love
to
see
on
the
dock,
for
myself.
B
So
as
a
developer,
so
that's
it.
I
think
that
you
can
find
the
link
of
the
pr
there
and
there
we
are
the
discussion
with
raphael
about
if
we
could
or
not
put
it.
B
On
the
diagnostic
repository
and
then
once
we
have
all
the
pieces,
there
maybe
write
down
the
full
guide
to
the
to
the
to
the
documentation
and
my
point:
why
was
maybe
we
should
find
a
way
to
each
time
that
you
could
add
a
piece
of
documentation?
We
should
try
to
make
it
visible
as
much
as
possible
so
yeah.
We
should
have
a
kind
of
discussion
there
between
let
them
in
the
dark,
repo
and
then
put
all
the
stuff
at
the
end
when
we
finish
on
the
documentation.
C
My
concern
actually
not
a
concern,
but
I
was
thinking
to
add
to
the
diagnostic
repository,
mostly
because
we
currently
have
a
a
guide
for
tracy
gc
and
how
you
can
trace
garbage
collection,
but
not
how
to
detect
memory
lake
using
that.
So
I
think
I
just
sent
the
the
link
here
that
it
would
fit,
and
I
assume
that
the
idea
of
this
this
documentation
in
the
repository
is
basically
when,
when
we
finish
the
the
the
issue
that
is
taking
too
much
time,
we
probably
would
expose
it
into
the
node.js
org
repository.
C
So
everyone
will
be
able
to
access
it
and
it
will
be
fully
available
of
the
the
at
least
of
the
the
steps.
So
the
only.
D
C
D
Because
it
it
depends
on
like
node
core,
I
could
see
if
it's
intended
for
collaborators
to
debug,
if
it's
intended
for,
like
the
greater
ecosystem,
I
think
the
website
would
probably
have
a
better
impact
right
and
then,
as
an
interim,
the
diagnostic
repo
is
is
a
good,
a
place
to
to
have
them,
as
as
like
node
core,
for
example,
unless
unless
they're
intended
for,
like
node
core
users,
there's
a
few
things
where
like.
If
it's
there,
you
know,
we
have
one
in
the
node
core
documentation,
which
is
investigating
memory
leaks
with
valgrind.
D
C
Yeah
and
the
the
point
with
moving
it
to
node.js
or
right
now
is
that
we
need
to
find
a
way
to
maintain
it,
because
once
we
release
a
single
version
and
it
the
trace
gc
changed
completely.
C
C
So
that's
my
my
concern
to
to
just
merge
it
in
node.js
work
just
for
reference.
I
will
paste
the
link
of
the
the
journey
to
those
documentations
in
the
chat.
B
C
B
I
just
tried
to
see
myself
as
a
node
developer
that
will
build
a
product
and
that
will
come
into
a
project
that
I
have
probably
five
years
of
developers
that
try
to
make
garbage
sheets,
and
then
you
find
that
they
are
out
of
memory
and
try
to
understand
what
what's
happened
and
yeah,
but
I'm
really
open.
To
put
it
back
to
the
diagnostic,
I
mean,
if
you
think
that
it's
really
the
way
to
the
way
to
go.
B
C
Actually,
my
my
point
is
because
your
your
guide
is
to
diagnose
memory
lake,
but
you
are
only
showing
a
tracy
tracy.
You
see,
but
in
fact
we
have
several
other
ways
to
to
trace
diagonal
to
trace
memory
lake
and
if
we
move
it
to
node.js
org.
C
B
B
C
External
ones,
internal
tools
can
can
be
you.
You
have
the
process,
memory
usage
that
you
can
just
put
in
a
set
interval,
for
instance.
This
is
a
way
to
track
the
memory
usage
and
also
when
you
expose
the
gcc
as
well.
I
I
feel
I
feel
that
is.
I
feel
that
it's
better
to
to
to
move
there,
because,
but
also
there
is
one
point
that
we
are
taking
too
much
time
to
finish
out
the
documents
to
move
to
the
node.js
work.
C
So
I
don't
think
that
we
will
able
to
finish
out
the
documents.
At
least
I
don't
have.
Currently,
I
don't
have
time
to
to
to
create
more
documents,
and
I
think
that
we
currently
have
good
ones,
and
we
should
probably
raise
a
new
issue
to
to
migrate.
A
few
talks
to
there
that
is
completed,
like
I
think,
cpu
is
completed.
C
Right
memory
is
almost
completed,
so
I
think
that
we
can
at
least
generate
a
new
issue
to
discuss
how
we
can
move
out,
collect
out
those
documents
in
a
I,
don't
know,
a
readable
way
for
end
users,
and
then
we
move
it
to
node.js
org.
D
B
D
B
Yep
great
thanks
and
yeah,
I
will
continue
on
that
and
for
the
rest
of
the
documentation,
after
that
I
probably
could
give
a
try
to
finish
remaining
parts
or
trying
to,
but
there
are
some
ones
that
are
really
I'm
really
not
familiar
with
like
a
little
db.
I
don't
use
it
too
much
so
yeah.
You
probably
have
to
make
kind
of
discovery
again
and
before.
C
D
C
In
the
clinquejs
as
well,
so
I
will
share
with
you
some
documents,
private,
if
you
want
so
I
can
guide
you
if
you
want.
C
D
D
And
it
sounds
like
if
you
have
time
to
take
a
look
at
it
actually,
looking
like
the
goal
is
to
get
to
that
point
where
that
documentation
has
all
the
different
areas,
and
even
just
like
hey
this
one
is
done.
These
three
need
space.
You
know,
need
some
stuff
and
I'm
going
to
work
on
these
that
you
know
getting
that
overall
view
and
then
picking
off
some
pieces
would
actually
be
pretty
pretty
valuable.
A
So
basically,
while
trace
gc
in
itself
is
a
useful
tool
for
debugging
memory,
because
the
other
aspects
are
the
higher
level
tools
and
methodologies.
For
example,
the
heap
dumping
itself,
which
comparatively
analyzes
multiple
snapshots
of
the
heap
and
makes
a
better
abstraction
and
observation
around
what
is
leaking,
which
is
the
memory
that
are
growing.
A
Those
kinds
of
documentation
is
still
not
out
there.
Then
the
trades
you
see
bringing
up
independently
can
cause
confusion
with
the
people,
so
the
idea
would
be
elevate.
The
documents
that
are
completed
memory
could
be
the
first
in
that
group
and
then
promote
the
trust
gc
alongside
that.
So
that
makes
a
complete,
coherent,
comprehensive
set
of
documentation
for
the
end
users
to
consume.
A
A
D
B
B
Yeah
the
way
that
I
tried
to
write
it,
it
was
also
in
that
way
to
say:
okay,
trust,
gc,
just
comment:
you
don't
have
to
make
snapshot
while
at
the
beginning,
one
after
and
then
put
the
both
and
go
there
before
you
can.
If
you
see
too
much
even
that
could
alert
you,
then
you
can
go
to
to
the
hip
snapshot
and
stuff
like
that,
so
yeah.
I
think
that
we
definitely
should
have
a
kind
of
guide
but
yeah
less
effort
first
and
then
you
can
move
them.
B
C
I
just
added
out
so
to
the
minutes
the
three
that
raise
a
new
issue
just
to
coordinate
the
migration,
because
we
have
a
few
tutorials
open
that
I
think
might
be
merged
to
the
node.js
or
once
the
section
is
done.
For
instance,
the
memory
is
almost
done.
C
Yeah,
I
think
that
we
can
discuss
in
this
issue
the
migration
issue
we
can
discuss
in
which
repository
it
should
show.
A
Our
original
plan
or
aspiration
was
to
move
to
node.js
dave,
but
for
whatever
reason
I
I
exactly
don't
remember
the
reason
why
we
we
are
not
moving
that
direction
either
that
it
itself
is
not
undergone
sufficient
maturity
curve
or
it's
not
yet
endorsed
by
the
community
properly.
I
I
don't
know
I.
D
Don't
I
think
the
node.js.dev
effort
is
kind
of
it's,
not,
it
hasn't
moved
forward
and
I
suspect
it
it
may
may
not
so.
A
C
A
When
we
close
the
issue,
the
label
gets
gets
off
automatically
or
still
it
appears
in
the
list
of
agenda.
Even
if
the
issue
is
closed,
I
don't
know
yeah
if
the.
D
A
B
C
A
A
C
C
D
D
A
C
Yeah,
I
think
we
can
just
skip
this
one
because
it
seems
same
state
as
last
meeting.
C
And
I
don't,
I
don't
think
that
mary
will
answer.
There's
another
person
in
charge
of
ll.
B
D
C
D
A
Yeah,
as
far
as
the
tool
is
concerned,
it
provides
a
unique
capability
which
I
don't
think
I
I
haven't
seen.
Debugging
core
files
is
provided
by
any
other
tool.
Of
course,
native
debuggers
provide
that,
but
they
lose
the
context
of
the
v8
engine
and
other
internal
data
structures.
So
l
node
provides
that
in
that
perspective,
it's
a
unique
capability,
I
would
say,
but
then
the
two
two
things
that
are
questionable
is
one
is
who
who
are
using.
You
know
who
are
using
a
little
node.
D
I
think
the
one
thing
I
would
do
like
if
somebody
wanted
to
reach
out
to
anton
wally
who's,
the
number
nine
there
he's
got
a
few
of
the
pr's.
I
at
least
at
one
point
he
seemed
interested
in.
Maybe
you
know
becoming
more
active
as
a
maintainer,
so
it
might
be
worth
picking
him
just
to
say
you
know.
Are
you
still
interested
in
in
helping
to
maintain
this
and
the
answer
might
be
if
he
says?
Yes,
we
just
make
him
one
of
the.
We
make
him
a
maintainer
to
move
it
forward
right.
D
D
D
D
A
A
C
Yeah,
I
think
that
the
sec,
the
second
option,
is
better
for
now,
because
I
I
don't
think
that
the
ping
will
be
will
be
like
an
instantane
action
for
anyone
and
yeah
the.
I
think
the
idea
of
the
re-evaluation
is
to
to
put
in
the
in
the
document
the
current
state
of
yeah
yeah,
so.
B
A
Yeah
yeah,
so
I
can
do
the
contact
part
conducting
anton
valley.
Part
he's
from
my
company
itself,
so
easy
for
me
to
contact
tony
take
up
the
pr
work
for
okay
adjusting
the
tier
list.
You
have
been
doing
it,
so
it's
easy
for
you
to
do.
Yeah.
B
I
don't
have
I
mean
any
experience
in
this
cartoon,
but
I
could
I
could
give
a
help
if.
D
A
A
A
Than
me,
that
is
basically
like
providing
confidence
on
either
side.
We
don't
want
him
to
think.
Oh
okay.
This
is
such
a
big
responsibility.
Okay,
so
on
the
other
hand,
we
also
are
having
people
who
are
willing.
So
it's
it.
It
makes
a
collaborative
effort
rather
than
an
individual
effort.
Yeah.
I
think
that's
here.
C
I
think
that
I
mean
chrome
devtools
is
used
broadly.
I
think
that
it
is
currently
in
the
in
the
trial
list
and
we
showed
currently
in
the
list.
It
is
not
classified
and
for
this
reason
that
the
target
is
to
to
move
to
target
three
to
tier
three,
and
I
think
that
we
shall
do
that.
C
I
think
it's
very
hard
to
create
a
knight
like
build
on
like
ci,
for
that
at
least.
D
C
You
have
a
headless
build
for
our
headless
package.
We
can
do
that,
but
since
the
target
is
three,
we
don't
it's
not
mandatory
to
have
a
ci.
A
C
Yeah
so
yeah.
I
think
that
we
can
just
change
in
the
document
to
to
move
the
chrome
dev
tools
to
tier
three
and
that's
how
I
guess
in
the
pr.
D
B
C
A
C
Yeah
this
one.
C
Okay,
I
just
don't
know
exactly
if
trace
events
is
internal
from
node
or
is
just
an
integration
from
v8.
A
If
I
understand
correctly
the
trace
option,
the
basic
capability
is
provided
by
v8
yeah,
but
then
you,
you
can
customize
the
events
to
add
or
incorporate
the
module
of
your
interest
so,
for
example,
trace
events.
A
Category
node
trace
event,
category
gc.
Likewise,
you
can
define
and
add
new
categories
to
the
trace
events,
which
would
cause
the
tracer
apis
to
qualify.
Those
trace
data
as
such.
D
C
But
I'm
not
sure
about
if
we
sh,
we
can't
move
it
to
tier
one,
because
this
is
still
spring
experimental
right.
C
The
target
tier
is
one,
but
this
is
still
experimental.
Let
me
see
if
diagnostics
report
is
experimental,
yet.
C
Yeah,
but
it
was
added
to
the
tier
list
to
tier
list
one
when
it
was
experimental
or
okay,
so
we
can't
move
the
the
trace
event,
so
we
can
at
least
so.
I
think
we
need
to.
C
A
So
the
the
other
question
is
what
is
stopping
trace
events
from
becoming
stable,
because
we
will
have
test
cases
in
the
ci
for
sure,
and
this
is
working
for
some
time-
that's
also
for
sure.
Usually
they
they
take
one
year
to
18
months
to
say:
okay,
we
have
evidence
of
it
being
sufficiently
churned
in
the
in
the
project
and
if
I
understand
correctly,
this
is
definitely
more
than
18
months
old
and
then
the
other
criteria
would
be
zero
outstanding,
bugs.
A
A
C
Yeah
absolutely,
but
I
yeah
I
mean
we,
so
we
we
have
two
actions
here.
The
first
one
is
not
not
more
and
not
move
trace,
gc
trace
events
to
tier
one
because
it's
not
stable
and
the
second
one
is
raise
a
new
issue
or
appear
to
to
move
trace
events
out
of
experimental.
A
So
I
I
will
bring
tony
the
pr
that
I
raised
for
elevating
inspector
to
stable,
because
that
has
all
the
qualifying
checklist.
Whatever
you
need
to
achieve
before
you
call
yourself
a
stable.
Is
that
checklist
is
there
in
the
pr?
So
you
can
see
if
those
checklists
are
applicable
for
trace
events
as
well,
it's
possible
that
you
don't
know
the
answer
for
some
more
checklist,
so
let
me
know
I
can
also
look
at
that:
okay
yeah,
for
example,
evidence
of
a
strong
usage
in
the
field.
C
Yeah,
so
so,
just
to
to
make
sure
we
can
close
the
issue
544,
because
we,
if
we
can't
move,
trace
events
and
if
it
is
moved
out
of
experimental,
we
can
reopen
this.
This
issue
yeah
sounds
good.
A
C
C
I
think
that
I
never
know
what
it
is.
Okay,
is
it
open
open
source
racing
framework
for
linux.
C
C
C
C
Yeah
I
mean
I
wouldn't
say
to
close
it,
I
will
give
a
shot
and
if
I
have,
if
I
think
that
is
not
valuable
or
is
not
maintained,
we
can
close
it
in
the
next
meeting.
A
C
C
Okay,
even
tracing
for
windows-
yes,
this
one.
I
have
sure
that
I
can
try,
because
I
don't
use
linux,
not
use
windows
for
a
long
time.
C
A
C
B
D
B
It's
like
that
and
for
one
of
them
that
we
did
it.
I
think
this
was
mdr
in
dump
or
mdbv8
someone
ping,
someone
else
to
say:
okay,
if
it's
okay
for
you
and
yeah
someone
that
did
we
didn't
mention
during
our
previous
meetings,
but
another
contributor,
not
contributor,
mention
it
in
the
pr,
and
then
you
say:
okay,
it's
okay
for
me,
so
at
at
least
yeah.
C
Yeah
I
a
studio
system
tab
some
years
ago
and
currently
it
is
very
related
to
the
trace
and
the
trace
works
very
well
in
solaris,
but
in
unix
like
in
ubuntu,
for
instance,
it
doesn't
work
well
and
and
to
bring
system
tap
for
duo's
system
like
linux
mint.
It
is.
There
are
several
challenges
and
there
is
bet.
Currently
there
are
better
options
for
that
like
ebpf,
so
it
will
false
in
the
in
the
rule
of
unity
capability.
B
Because
I
find
a
whole
website,
I
don't
know
if
it's
the
right
tool.
So
if
you
have
a
link
to
share
okay,
yeah
actually
find
the
proposal
of
the
tool.
What
let's
make
for
my
computing
system,
doing
the
scripted
language
for
all
and
tool
for
data
moving
instrumenting
running
production
based
rank
system.
C
Yeah,
it's
a
trace
event
system,
okay,
but
I
I
think
that
system
tap
and
the
trace
files
in
the
same
the
same
in
the
same
rule
I
mean
the
trace,
is,
I
don't
know,
is
widely
used
and
I
don't
know
if
it
is
currently
used
since
ebps
is
a
thing.
C
But
since
I
don't
use
the
letters-
and
I
don't
think
that-
actually
I
can
say
that,
but
I
think
someone
might
use
that
use
that
so,
but
I
am
unable
to
to
to
evaluate
it
by
myself.
C
We
can
remove
it
from
the
list,
but
because
currently
node.js
does
not
support
system
tab
or
the
trace
directly
it
can
be
used.
I
think
it
falls
in
the
same
rule
of
of
linux.
Perf
linux
perf
is
not
fully
supported.
It
is
not
at
least
it's
supported
by
v8,
but
it
not
it
doesn't
f.
It
doesn't
follow
the
rules
of
versioning
like
if
v8
needs
to
change
it.
It
will
break
node.js
users
without
a
single
change
same
for
major
change
or
something
like
that,
because
trace
events
is
not
tier
one.
C
C
B
Okay,
just
yeah
go
back
to
say
to
be
sure
that
we
did
not
forget
anything
about
a
load
direction,
contact
contributor
and
I
will
raise
a
pair
to
delete
it.
C
Yeah,
I
think
I
think
it
is
like
a
synchronous
task.
You
can
either
create
a
peer
or
talk
with
someone,
but
I
think
that
the
pr
should
be
created
anyway.
B
B
Anyway
and
then,
if
you
have
a
good
answer
or
something
we
could
work
it
back
in
also,
we
have
the
cdt
ct
was
about
moving
into
tier
of
three.
B
C
B
Yeah,
that's
what
I
note
for
the
trace
events
close
the
issue
create
a
new
issue
to
see
if
you
could
pass
it
as
stable.
Yes,
exactly
and
jerisha,
you
should
send
me
something.
I
think,
for
example,.
B
B
Okay
for
a
twu
deleted
from
the
list
yeah
and
same
for
the
trace
and
assistant
yeah.
Sorry.
B
A
I
been
there
last
time
this
time,
I'm
not
going
yeah
okay,
but
when
we
vendor
or
otherwise
we
had
a
session
on
diagnostics
in
the
club
summit
this
year,
we
don't
have
it.
That's
fine.