►
From YouTube: Update on OOM Must Fail Fast
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
last
time,
I
presented
on
whom
out
of
memory
must
fail
fast
by
out
of
memory.
I
include
both
heap
memory
and
stack,
and
this
is
more
generally
a
problem
of
the
machine
hitting
a
situation
where
it
cannot
continue
according
to
the
language
spec
and
an
exceptional
thing
that
has
happened
and
how
to
treat
the
exceptional
thing
right
now.
A
So
one
of
the
options
that
that
we
discussed
is
that
well,
first
of
all,
a
constraint
on
the
proposal
that
came
from
the
discussion
last
time
is
that
the
web
currently
depends
on
out
of
memory
and
out
of
stack,
resulting
in
catchable
exceptions
and
therefore
we
cannot
simply
make
it
always
fail
fast
without
breaking
the
web.
And
of
course
our
prime
directive
is
don't
break
the
web.
A
So
so
one
thing
we
need
would
be
a
way
to
do
and
opt
in,
and
the
death
before
a
confusion
here
is
not
intended
to
be
a
serious
proposal
for
what
the
name
of
it
is.
But
the
point
is
that
there'd
be
some
mechanism
to
opt
in
and
once
you
opt
in,
then
whatever
the
unit
of
preemptive
termination,
the
unit
of
computation,
all
of
which
must
be
suspected
to
be
corrupt
at
that
point,
that
all
of
that
gets
abandoned
on
out
of
memory.
A
It's
also
an
issue
of
the
fact
that
in
JavaScript
pretty
much
everything
you
call
might
decide
to
throw
an
exception
and
people
adding
new
exception
throws
to
existing
api's,
don't
normally
think
of
themselves
as
doing
something:
that's
not
upwards
compatible
from
the
previous
case,
so
the
problem
is
practically
also
the
issue
of,
if
an
exception
happens
in
a
situation
where
you
were
really
counting
on
no
exception
happening.
How
can
you
also
call
abandonment
there.
A
So
Baldemar
suggested
I
think
he
used
afraid
that
the
term
no
throw
I
should
have
consulted
with
Waldemar
before
putting
the
slide
together,
but
it
was
just
part
of
my
inference
from
from
the
discussion
with
last
time
and
the
discussion
on
a
github
thread.
So
the
so
one
thing
we
could
imagine
doing
is
placing
critical
sequences
of
code
inside
a
no
throw
block
where,
if,
if
execution
of
the
of
the
block
itself
terminates
exceptionally,
then
the
entire
unit
of
preemptive
termination,
the
entire
unit
that
is
now
suspected
to
be
corrupt,
now
gets
abandoned.
A
This
is
very
slow,
Kay,
very
slow
to
update
between
here
and
the
screen,
so
the
terminate
does
not
subsume
the
need
for
the
death
birth
before
a
confusion,
because
it's
still
the
case
that,
if
you
didn't,
if
there
was
no
opt
in
for
saying
that
out
of
memory
and
such
low
levels,
errors
in
general
caused
termination,
then
one
could
still
use
the
purposeful
inducing
of
out
of
memory
to
cause
attacks,
as
we
actually
seen
in
the
wild
as
I
as
I
showed
an
example
of
last
time.
So
altogether.
A
A
Yes,
yeah
the
the
death
before
confusion
doesn't
deal
with
the
case
you
are
raising,
which
is
a
an
exception
that
was
thrown
by
user
code.
That's
considered
normally
a
catchable
exception,
but
happens
to
go
through
something
that
was
a
critical
operation
that
wasn't
prepared
to
recover
from
the
critical
exception.
A
But
an
attacker
could
still
cause
an
out
of
memory
exception
in
a
position
where
they're
able
to
then
catch
it
before
it
gets
thrown
through
something
critical,
and
it
is
true
that
if
you
had
marked
everything
critical
with
this
terminate
pattern,
then
the
attacker
inducing
out
of
memory
and
then
catching
it
in
theory
would
not
have
actually
corrupted
the
critical
data
structure,
but
they
would
have
corrupt.
They
would
have
corrupted
pretty
much
any
other
low-level.
A
Stateful
update
that
hadn't
been
able
to
complete
so
I'm
I'm
I'm,
going
to
hypothesize
that
the
issue,
your
your
questioning,
is
whether
we
can
just
deal
with
terminate
and
make
it
program
a
responsibility
to
mark
all
critical
state
state
updates
in
order
to
restore
consistency
and
I.
Think
I
think
I
can
say
that.
Yes,
that's
an
open
question.
A
A
Okay,
yeah
also
I
am
actually
recording
this
part,
so
so
the
so
when
I
break
for
questions
afterwards.
If
there's
time
that
will
be
the
more
important
time
to
be
taking
notes
in
any
case,
there's
a
unit
of
what
is
the
unit,
the
the
the
unit
of
pre-emptive
determination,
how
much
computation
do
we
terminate
either
because
of
the
the
opt-in
or
because
of
the
explicit
call
to
terminate
once
upon
a
time.
A
The
agent
was
a
perfectly
valid
unit,
the
where
objects
within
the
same
agent
have
Kronus
access
to
each
other
and
therefore
everything
within
the
agent
must
be
assumed
to
be
corrupt.
But
it
used
to
be
the
case
that
between
different
agents,
there
was
only
a
synchronous,
interaction,
and
then
we
introduced
shared
array
buffers
and
with
shared
array.
A
Then
then,
then,
something
protect
potentially
as
large
as
the
agent
cluster
might
need
to
be.
The
unit
that
gets
abandoned,
I'm,
hoping
that
we
can
refine
the
semantics
of
shared
array
buffer
so
that
it
becomes
a
firewall
against
the
contagion
of
corruption,
so
that
we
can
go
back
to
only
having
the
agent
be
the
necessary
unit
of
pre-emptive
termination.
A
A
We've
got
the
notion
of
an
import
namespace,
a
module
registry.
We
don't
yet
have
a
really
at
the
loader,
but
that's
that's
coming.
We've
got
a
proposal
for
a
compartment
which
is
essentially
a
reified
evaluation
context
where
you
have
multiple
compartments
per
realm,
so
these
are
sort
of
successively
coarser
things,
except
that
there
is
this
open
question
of
the
unit
of
pre-emptive
termination,
where
you
would
associate
a
resource
budget
with
that
unit.
A
A
An
agent
cluster
synchronous
computation
can
happen
within
an
agent
cluster,
but
agent
clusters
are
only
asynchronously
coupled
to
each
other,
so
it
seems
like
you,
don't
have
to
go
larger
than
the
agent
cluster
and
then
I
include
just
for
a
completeness
for
thinking
about
the
overall
ecosystem
that
the
world
of
computation
as
a
whole,
the
internet,
the
web,
is
organized
and
also
in
terms
of
computation
happening
on
separate
machines
where
the
machines
are
mutually
suspicious
and
talking
to
each
other
over
cryptographic.
Protocols
where
a
machine
or
a
data
center
is
a
unit
of
separate
administration.
A
In
the
browser,
the
there's
the
issue
of
what
happens,
the
browser
gives
us
a
good
context
for
examining
what
happens
on
termination,
such
as
making
tabs
dead
or
forcing
a
refresh
site.
Isolation
would
align
the
process
notion
with
the
origin
notion,
so
prou
origin
and
process
did
not
appear
previously
because
they
aren't
JavaScript
concepts
in
the
embedded
context.
There
is
avoiding
there's
rebooting
devices
in
a
transactional
context.
A
You
can
think
of
terminate
as
a
boarding,
a
transaction
falling
back
to
a
previously
consistent
state
and
the
Erlang
Erlang
language
and
the
Keiko's
operating
system
show
that
building
highly
reliable
systems
that
are
resilient
to
their
own
bugs.
The
key
element
is
fail,
stop
components
and
the
ability
to
have
supervisors
or
keepers
that
are
outside
the
component
that
run
on
other
resources.
That
can
react
to
the
sudden
failure
of
the
component
is
Peter
here
downstairs:
Peter.
Are
you
online
okay,
so
I'm
going
to
skip
these
two
slides
because
they
were
for
Peter
to
talk
to?
A
A
Yeah,
so
a
goreck
is
our
plans
are
to
actually
use
the
excess
virtual
machine.
Dex
s.
Virtual
machine
is,
of
course,
built
primarily
for
embedded
devices,
but
we're
actually
planning
to
use
it
on
blockchain
for
running
smart
contracts
and
we're.
We
have
this
unit
of
deterministic
replication,
which
is
this
swing
set,
which
is
a
set
of
JavaScript,
what
we
call
vats,
which
are
essentially
agents
but
without
shared
array
buffers,
but
we're
going
to
do
a
resource
allocation
per
vat.
A
Even
though
there's
no
concurrency
between
the
bats,
the
bats
are
only
asynchronously
coupled,
so
you
can
terminate
them
separately
with,
while
preserving
consistency.
There's
no
concurrency
here
so
they're
not
really
separate
agents
in
the
conventional
manner,
but
we
need
to
be
able
to
terminate
them
separately
with
separate,
giving
having
given
them
separate
budgets
so
that
the
swingset
as
a
whole
can
continue
to
operate
after
anyone
that
has
exhausted
its
budget
well,
leaving
the
swingset
as
a
whole
as
a
unit
of
deterministic
replication.
A
So
the
remaining
element
of
the
API
is
just
like
we're:
creating
a
compartment
API
for
reifying
the
notion
of
an
evaluation
context
and
having
reflective
access
for
controlling
it
and
reifying
a
notion
of
a
realm
that
there
would
be
a
that
reifying
an
agent
through
a
agent
API,
so
that
you
can
have
a
reflective
control
of
what
happens
within
the
agent,
for
whatever
the
unit
of
pre-emptive
determination
is.
I.
A
A
So
so
agent
was
an
example,
but,
but
quite
literally,
given
that
the
spec
has
a
concept
of
agent
and
a
concept
of
agent
cluster,
assuming
that
the
current
spec
categories
of
those
things
remain
in
place,
then
just
like
the
spec
has
an
unrealized
notion
of
realm,
which
we're
now
going
to
reify
I
would
expect.
Actually,
we
would
have
eventually
an
agent
API
and
an
agent
cluster
API
for
programmatically,
creating
new
agents
and
creating
new
agent
clusters.
A
An
example
of
something
different
issues
are
properly
reified
through
through
different
reflective
api
in
order
for
JavaScript
code
to
act
as
host
to
other
JavaScript
code.
So,
for
example,
when
JavaScript
code
delegates
to
the
host
the
question
of
his
evaluation
enabled
that's
something
that's
appropriate
to
be
done
at
the
compartment
level
when
JavaScript
delegates
to
the
hosts
to
say
what's
the
next
job
that
should
be
allowed
to
run
among
the
different
jobs
on
the
different
job
queues
that
doesn't
make
sense
that
a
compartment
level
doesn't
make
sense
on
an
agent
planet
on
a
realm
level.
A
A
The
error
keeper
would
get
called
with
not
the
same
error
object
because
there's
no
shared
heap,
but
a
copy
of
the
error
object
that
contains
an
adequate
copy
of
the
diagnostic
information.
So
the
Diagnostics
can
can
diagnostic
information
can
be
carried
across
to
explain
what
the
problem
was,
and
that's
it
now
that
I'm
officially
breaking
for
questions.
I
will
also
officially
turn
off
record.