►
Description
Demystifying (JavaScript) Engines - Alejandro Oviedo, nearForm
"How a JavaScript engine works? What are its basic components? How to measure its performance? What is JIT compilation? Stigmatization: is JavaScript fast enough? are some of the questions I think we currently fail to answer in a, somewhat, short and direct way.
The most advanced JavaScript engines (V8, Chakra and SpiderMonkey) are now Open Source. I think that sets the bar pretty high for the upcoming generation of engines along with the runtimes that are using them - Node.js, JXCore, etc - and challenges developers to try to understand a whole new group of concepts hidden in the execution of their JavaScript applications.
Crankshaft, unoptimized hell, LLVM and asm.js sound like names of main characters or places of a George R. R. Martin’s novel. I’ll talk not only about their definitions but also about their cross-engine representation and status."
A
Hey
everyone,
my
name
is
Alejandro,
and
this
talk
is
about
JavaScript
engines.
You
can
find
me
on
Twitter
and
github
by
that
handle.
Please
note
that
the
first
Oh
is
zero
and
you
can
also
find
in
that
link
all
the
resources
and
under
slides
to
you.
The
goal
for
the
talk
is
to
do
an
overview
of
the
most
important
concepts
used
in
JavaScript
engines
in
question.
A
Everything
else
before
we
continue
I
wanted
to
say
why
I
think
you
should
care
I,
believe
that
being
able
to
understand
the
optimizations
that
takes
place
in
your
JavaScript
programs
gives
you
a
unique
perspective
when
measuring
performance.
I
start
my
path
going
through
the
history
of
JavaScript
engines
and
found
an
inflection
boom
around
2006.
Before
the
time
the
implementations
were
fairly
straightforward,
the
engine
would
choke
the
source
code
and
parse
it
to
an
abstract,
syntax
tree
or
ast.
A
The
final
step
needed
for
running
the
program
is
what
I
call
here:
an
execution
phase,
and
it's
often
described
as
a
really
big
switch
statement,
that
for
each
instruction
it
will
shunt
to
the
portion
of
code
that
implements
its
logic
like
in
most
high-level
languages.
Javascript
will
not
deal
with
memory
explicitly,
you
can
create
objects
and
those
objects
will
be
allocated
internally
by
the
engine.
This
object
can
also
be
in
reference
and
in
order
to
be
used
those
precious
weights
of
memory,
the
system
will
need
a
garbage
collector.
A
There
are
different
strategies
to
implement
garbage
collectors,
but
we'll
leave
those
details
for
later
turns
out
this
setup.
A
straightforward
interpreter
is
considerably
slow,
well
slow
means
implicitly
comparing
to
the
performance
of
a
C
or
C++
program.
After
all,
the
optimizations
are
of
type
a
good
brilliant
people
worked
on
improvements
over
this
architecture
in
the
70s,
for
Fortran
and
in
the
80s
for
solve
and
Smalltalk
runtimes,
and
they
come
up
with
this
great
idea
of
adaptive
optimization
and
we
are
not
seeing
the
slides
here.
A
Let's
do
that.
The
idea
of
adaptive
optimizations
it
is
to
identify
the
pieces
of
the
program.
Derek
executed
too
often
also
known
as
hot
functions,
and
to
compile
them
during
execution.
Hence
the
name,
just-in-time,
compiler
or
sheet
compiler.
For
short,
after
calculation,
the
engine
wouldn't
have
any
other
head
for
the
execution
of
those
functions,
while
just
the
interpreter
with
just
interpreter
the
functions
will
have
to
be
interpreted
from
byte
code,
each
time
they
are
executed.
Let
me
get
the
Wi-Fi.
A
Yeah
there
you
go
so
this
approach
is
also
a
great
opportunity
to
apply
optimistic
optimizations
in
dynamic
languages
like
JavaScript,
for
example.
Collecting
information
about
the
context
of
a
function
call
could
up
in
the
possibilities
for
type
specializing
optimizations
in
order
to
optimize
property
access
in
dynamic
languages,
Ilyn,
caches
or
ICS
for
short,
were
invented.
Ilyn
caches
are
a
way
to
see
the
fast
path,
the
first
time
the
engine
access
a
property.
It
will
use
a
slow
path,
but
will
record
the
steps
needed
to
get
it
global
variables.
A
Variables
from
closures
and
prototype
chains
could
also
be
optimized
by
England
caches.
Imagine
that
using
I
sees
a
hundred
objects.
Laying
a
prototype
chain
could
have
almost
the
same
performance
that
accessing
a
property
from
an
object
with
no
prototype.
That's
insane
and
that's
how
big
improvement
boost
you
could
get
only
by
using
ICS
be
aware
that
some
features
of
JavaScript
will
inhave.
It
type
specialize
in
optimizations
like
the
eval
function,
the
width
operator
or
try
catch
blocks.
A
The
basis
for
most
engines.
Implementations
consists
of
an
interpreter
with
two
additional
compilers
on
your
left,
the
one
that
optimize
compilation
time
and
on
the
right,
the
one
that
optimize
execution
time.
They
also
called
optimizing
compiler
and
the
other
one
an
optimizing
compiler.
The
unoptimized
one
generally
creates
Ilyn
caches
and
helps
collect
type
information.
Also,
the
generated
code
by
this
compiler
will
not
use
CPU
registers
for
variables.
A
Switching
to
a
real-world
architecture
is
panel
monkey
the
engine
that
powers
Firefox.
It's
not
too
far
from
the
previous
example.
They
will
count
with
an
interpreter
and
two
additional
compilers.
It
will
initially
transform
the
source
code
into
bytecode
and
will
execute
it
without
compilation.
After
a
certain
amount
of
times
the
function
is
executed,
the
system
will
mark
that
function
as
candidate
for
compilation.
A
If
the
number
of
times
the
function
is
executed
passes
a
second
threshold,
the
engine
will
mark
the
functions
as
candidate
for
a
really
really
good
optimization
and
that's
when
Iron
Monkey
kicks
in
and
with
the
bytecode
plus.
The
type
information
collected
compiles
the
function
to
machine
code.
Again,
unlike
the
previous
case,
where
both
compilers
will
bail
out
to
the
interpreter.
In
this
case,
the
code
will
bail
out
only
to
the
base
limit
sheet.
Spidermonkey
has
a
way
to
keep
the
internal
representation
of
the
vaneless
baseline
JIT
up-to-date.
A
Even
if
you
have
type
changes,
checker
car,
the
engine
that
powers
edge
shares
a
similar
architecture
to
you,
spider
monkey,
it
has
an
interpreter,
an
optimizing
compiler
and
an
optimizing
compiler.
The
interesting
part
is
that
you
can
fire
additional
threats
to
compile
or
to
run
the
garbage,
garbage,
collector,
say:
you're
running
the
engine
in
a
fork
or
CPU.
In
theory,
you
could
take
advantage
and
paralyzed
Jeep
compilation
in
three
orders
of
those
cars,
both
Quora
and
spider.
A
The
full
cogent
compilers
assemble
this.
Despite
monkey
baseline
compiler,
both
will
create
inline
caches.
If
be
a
profiler
identifies
that
a
function
is
taking
a
good
proportion
of
the
execution
time,
it
will
then
notify
the
engine
to
optimize.
It
both
Bank
shaft
and
to
refine
optimized
code
with
type
information
turbofan.
It's
based
on
a
sea
of
node
internal
representation,
while
crankshaft
uses
hydrogen
and
lithium
a
high
level
and
a
low-level
internal
representations
respectively.
A
Javascript
called
the
engine
that
powers
Safari
has
also
a
four
tier
architecture,
an
interpreter
and
an
optimizing
compiler
and
tree
optimizing.
Compilers
DFG,
an
FTL,
the
log
level
interpreter
and
the
baseline
compiler,
both
uses,
inline
caches,
the
engine
will
apply
heuristics
to
know
which
level
of
optimization
is
needed
and,
interestingly
enough,
at
any
point,
this
tag
hand
can
have
entries
of
generated
core
code
from
all
four
tiers.
A
You
can
see
that
the
FGL
has
a
component
inside
it's
LLVM
and
it's
an
open
source
project
that
applies
aggressive,
optimizations
and
I
have
all
sorts
of
applications
outside
javascriptcore,
for
example,
in
Agnes,
QuickTime
and
C
to
JavaScript
compiler.
The
engine
will
gather
type
information,
the
bytecode
and
transform
that
into
a
lower-level
internal
representation
to
fit
that
into
LLVM.
A
They
also
recently
suite
shipped
an
e
back
end
for
the
FTL
compiler
called
b3
in
order
to
keep
the
optimizations
they
warrant.
But
you
reuse,
compilation
time,
which
is.
We
fully
talked
about
the
different
architectures
for
most
advanced
JavaScript
engines,
and
now,
let's
talk
about
the
optimizations
that
they
are
all
applying.
A
Let's
say
you
have
a
look
executing
many
times
and
inside
its
body
a
single
expression
of
adding
the
variable
were
incremented
multiplied
by
some
arbitrary
number.
The
reasonable
performance
improvement
would
be
to
make
the
calculations
once
and
reference
it
through
a
temporary
variable
in
all
the
iterations
all
the
engines
mentioned.
Your
applies
these
optimizations
internally
and
it's
called
loop
invariant
code
motion.
A
One
of
the
simplest
performance
improvements
the
engine
could
have
or
a
JIT
compiler
could
applied,
is
called
function.
Inlining.
Let's
come
back
to
the
canonical
loop
and
inside
its
body.
We
execute
a
function.
If
the
loop
iterates
a
certain
amount
of
time,
the
profiler
will
identify
the
function
as
hot
and,
if
some
condition
supply
it
will
grab
the
functions
body
and
paste
it
directly
inside
a
loop.
A
Now
those
conditions
could
depend
on
the
size
of
the
function,
the
size
of
the
generated
code
for
that
function,
and
so
on.
Now
you
might
be
wondering
why
it
should
be
far
since
it's
the
same
code
in
low
level
programming
languages
like
assembly.
Calling
a
function
would
end
up
in
a
context
which
it
will
have
to
save
all
the
current
status.
A
Bush
did
research
to
the
stack-on
before
returning.
It
will
have
to
resume
the
previous
context
pop
the
saved
registers
from
the
stack.
Let's
continue
with
the
next
optimization.
Imagine
a
loop
with
just
a
sum
expression,
or
it
could
be
an
expression
you
want,
but
it
doesn't
have
side
effects
even
like
a
assigning
to
a
variable.
A
A
Generational
garbage
collectors
will
grip
objects
by
their
lifespan
and
we'll
assume
that
young
objects
are
more
likely
to
die
than
all
objects.
This
kind
of
the
strategy
will
create
new
objects
in
a
nursery
space
and
promote
long-lived
objects
to
a
tenner
space
incremental
garbage
collectors
interleave
their
work
with
the
activity
from
the
main
program
producing
shorter
passes,
on
the
contrary,
are
stopped.
The
world
strategy
would
halt
the
execution
of
the
program
until
a
full
collection
is
done.
A
A
In
this
link,
you
can
find
all
the
resources
that
I
use
while
working
in
this
presentation.
If
you
want
to
read
more
about
JIT,
compilers
or
garbage
collection-
and
you
are
interested
in
all
the
details-
there's
a
lot
of
material
in
there.
You
can
also
find
me
around
I'm
working
on
a
way
to
detect
on
runtime,
which
optimizations
are
enabled
and
I
had
so
far
good
results,
I'm
able
to
distinguish
those
sanctions
who
use
hidden
classes,
dead,
code,
elimination
and
loop,
invariant
code
motion.
Hopefully
I
will
get
to
two
other
optimizations
to
you.
A
A
good
question
on
this
topic
would
be.
How
do
you
measure
performance
for
a
JavaScript
engine
and
it's
not
an
easy
answer?
There
are
a
lot
of
benchmarks
out
there
to
test
all
the
edge
case
you
may
find,
but
certainly
micro
benchmarks,
doing
measurements
for
small
operations
are
different.
Loop
constructs
like
for
loop,
incrementing,
D
command
G
will
not
show
you
the
whole
picture.
That
being
said,
I
think
we
should
strive
for
maintainable
and
clean
code.
All
the
optimizations
techniques
that
I
came
across
had
reasonable
requirements
to
apply
like
functions
to
be
monomorphic.