High Performance JavaScript

High Performance
JavaScript
Andreas Gal

(with lots of help from David Mandelin and
David Anderson)

July 28, 2011 Lancaster, UK

Thursday, July 28, 2011

Power of the Web



How did we get
here?
• Making existing web tech faster and
faster
• Adding new technologies, like video,
audio, integration and 2D+3D
drawing



The Browser



Getting a Webpage
twitter.com
199.59.149.198



Getting a Webpage

GET / HTTP/1.0 twitter.com
(HTTP Request) 199.59.149.198



Getting a Webpage

<html>
<head>
<title>Twitter / Home</title>
</head>
<script language="javascript">
function doStuff() {...}
</script>
<body>
...

(HTML, CSS, JavaScript)



Core Web
Components



Core Web
Components
• HTML provides content



Core Web
Components
• CSS provides styling



Core Web
Components
• CSS provides styling
• JavaScript provides a programming
interface



New Technologies

• 2D Canvas
• Video, Audio tags
• WebGL (OpenGL + JavaScript)
• Local Storage



DOM

(Source: http://www.w3schools.com/htmldom/
default.asp)


CSS
• Cascading Style Sheets
• Separates presentation from content
.warning {
color: red;
text-decoration: underline;
}

• <b class=”warning”>This is red</b>


What is JavaScript?



What is JavaScript?

• C-like syntax



What is JavaScript?

• C-like syntax
• De facto language of the web



What is JavaScript?

• C-like syntax
• De facto language of the web
• Interacts with the DOM and the
browser



C-Like Syntax
• Braces, semicolons, familiar
keywords

if (x) {
for (i = 0; i < 100; i++)
print("Hello!");
}



Displaying a Webpage



• Parsing, JavaScript engine executes
code as it is encountered.
• This can change DOM, or even
trigger a “reﬂow” (layout)



• Layout engine applies CSS to DOM



• Computes geometry of elements



• Computes geometry of elements
• Finished layout is sent to graphics
layer


Run to completion
• JavaScript is executed during HTML
parsing. Semantically , nothing can
(*)

proceed until JS execution is done.
• Very different VM latency
requirements than Java or C#.
• Sub millisecond compilation delays
matter.



The Result



JavaScript

• Invented by Brendan Eich in 1995
for Netscape 2
• Initial version written in 10 days
• Anything from small browser
interactions, complex apps (Gmail)
to intense graphics (WebGL)



Think LISP or Self, not Java




• Untyped - no type declarations




• Multi-Paradigm – objects, closures,
ﬁrst-class functions




• Multi-Paradigm – objects, closures,
ﬁrst-class functions
• Highly dynamic - objects are
dictionaries



No Type Declarations

• Properties, variables, return values
can be anything:
function f(a) {
var x = 72.3;
if (a)
x = a + "string";
return x;
}




can be anything:
function f(a) {
var x = “hi”;
if (a)
x = a + 33.2;
return x;
}




can be anything:
function f(a) { if a is:
var x = “hi”; number: add;
if (a) string: concat;
x = a + 33.2;
return x;
}



Functional
• Functions may be returned, passed
as arguments:

function f(a) {
return function () {
return a;
}
}
var m = f(5);
print(m());



Objects
• Objects are dictionaries mapping
strings to values
• Properties may be deleted or added
at any time!

var point = { x : 5, y : 10 };
delete point.x;
point.z = 12;



Prototypes



Prototypes
• Every object can have a prototype
object



Prototypes
object
• If a property is not found on an
object, its prototype is searched
instead



Prototypes
object
• If a property is not found on an
object, its prototype is searched
instead
• … And the prototype’s prototype,
etc..



Numbers

• JavaScript specifies that numbers
are IEEE-754 64-bit floating point
• Engines use 32-bit integers to
optimize
• Must preserve semantics: integers
overflow to doubles



Numbers
var x = 0x7FFFFFFF; int x = 0x7FFFFFFF;
x++; x++;

JavaScript C++
x 2147483648 -2147483648



JavaScript
Implementations
• Values (Objects, strings, numbers)
• Garbage collector
• Runtime library
• Execution engine (VM)



Values

• The runtime must be able to
query a value’s type to perform the
right computation.
• When storing values to variables or
object ﬁelds, the type must be
stored as well.



Values
Boxed Unboxed
Purpose Storage Computation
Examples (INT32, 9000) (int)9000
(STRING, “hi”) (String *) “hi”
(DOUBLE, 3.14) (double)3.14
Deﬁnition (Type tag, C++ value) C++ value

• Boxed values required for variables, object
ﬁelds
• Unboxed values required for computation


Boxed Values



Boxed Values
• Need a representation in C++



Boxed Values
• Easy idea: 96-bit struct (LUA)
• 32-bits for type
• 64-bits for double, pointer, or
integer



Boxed Values
• Easy idea: 96-bit struct (LUA)
• 32-bits for type
• 64-bits for double, pointer, or
integer
• Too big! We have to pack better.


Boxed Values
• We used to use pointers, and tag the
low bits (V8 still does)
• Doubles have to be allocated on the
heap
• Indirection, GC pressure is bad
• There is a middle ground…


Nunboxing
IA32, ARM



Nunboxing
IA32, ARM

• Values are 64-bit



Nunboxing
IA32, ARM

• Doubles are normal IEEE-754



Nunboxing
IA32, ARM

• How to pack non-doubles?



Nunboxing
IA32, ARM

• How to pack non-doubles?
• 51 bits of NaN space!



Nunboxing
IA32, ARM

Type Payload
0x400c0000 0x00000000
63 0



Nunboxing
IA32, ARM

Type Payload
0x400c0000 0x00000000
63 0

• Full value: 0x400c000000000000



Nunboxing
IA32, ARM

Type Payload
0x400c0000 0x00000000
63 0

• Full value: 0x400c000000000000
• Type is double because it’s not a NaN



Nunboxing
IA32, ARM

Type Payload
0x400c0000 0x00000000
63 0

• Full value: 0x400c000000000000
• Type is double because it’s not a NaN
• Encodes: (Double, 3.5)



Nunboxing
IA32, ARM

Type Payload
0xFFFF0001 0x00000040
63 0



Nunboxing
IA32, ARM

Type Payload
0xFFFF0001 0x00000040
63 0

• Full value: 0xFFFF000100000040



Nunboxing
IA32, ARM

Type Payload
0xFFFF0001 0x00000040
63 0

• Value is in NaN space



Nunboxing
IA32, ARM

Type Payload
0xFFFF0001 0x00000040
63 0

• Type is 0xFFFF0001 (Int32)



Nunboxing
IA32, ARM

Type Payload
0xFFFF0001 0x00000040
63 0

• Type is 0xFFFF0001 (Int32)
• Value is (Int32, 0x00000040)


NaN boxing



NaN boxing
• Nunboxing is a word-play on NaN
boxing



NaN boxing
boxing

• NaN boxing is like Nunboxing, but
prefers pointers over doubles (mask to
get a pointer, shift to get a double)



NaN boxing
boxing

• NaN boxing is like Nunboxing, but
prefers pointers over doubles (mask to
get a pointer, shift to get a double)

• Attributed to Apple’s JSC, but really
invented by Ed Smith/Adobe (I think)



Punboxing
x86-64

63 Type 47 Payload 0

1111 1111 1111 1000 0 000 .. 0000 0000 0000 0000 0100 0000



Punboxing
x86-64


1111 1111 1111 1000 0 000 .. 0000 0000 0000 0000 0100 0000




Punboxing
x86-64


1111 1111 1111 1000 0 000 .. 0000 0000 0000 0000 0100 0000

• Bits >> 47 == 0x1FFFF == INT32



Punboxing
x86-64


1111 1111 1111 1000 0 000 .. 0000 0000 0000 0000 0100 0000

• Bits >> 47 == 0x1FFFF == INT32
• Bits 47-63 masked off to retrieve payload



Punboxing
x86-64


1111 1111 1111 1000 0 000 .. 0000 0000 0000 0000 0100 0000

• Bits >> 47 == 0x1FFFF == INT32
• Bits 47-63 masked off to retrieve payload
• Value(Int32, 0x00000040)


Nunboxing Punboxing

Fits in register NO YES

Trivial to decode YES NO

Portability 32-bit only* x64 only

* Some 64-bit OSes can restrict mmap() to 32-bits



Garbage Collection
• Need to reclaim memory without
pausing user workﬂow, animations,
etc
• Need very fast object allocation
• Consider lots of small objects like
points, vectors
• Reading and writing to the heap
must be fast


Object Representation
• JavaScript objects are very different from
Java objects

• Start empty, grow and shrink over time.

• We use a header with a variable number of
built-in slots, malloc() beyond that.

• Predicting number of built-in slots to use
is black magic.



Mark and Sweep



Mark and Sweep
• All live objects are found via a
recursive traversal of the root value
set



Mark and Sweep
set
• All dead objects are added to a free
list



Mark and Sweep
set
list
• Very slow to traverse entire heap



Mark and Sweep
set
list
• Very slow to traverse entire heap
• Building free lists can bring “dead”
memory into cache


Improvements



Improvements

• Sweeping, freelist building have
been moved off-thread



Improvements

• Sweeping, freelist building have
been moved off-thread
• Marking can be incremental,
interleaved with program execution



Generational GC
• Observation: most objects are short-
lived
• All new objects are bump-allocated
into a newborn space
• Once newborn space is full, live objects
are moved to the tenured space
• Newborn space is then reset to empty



Generational GC
Inactive Active
Newborn
8MB 8MB
Space

Tenured Space



After Minor GC
Active Inactive
Newborn
8MB 8MB
Space

Tenured Space



Barriers

• Incremental marking, generational
GC need read or write barriers
• Read barriers are much slower
• Write barrier seems to be well-
predicted?



Unknowns
• How much do cache effects matter?
• Memory GC has to touch
• Locality of objects
• What do we need to consider to
make GC fast?
• Lots of research on Java. Almost
nothing on JavaScript. Very different
heaps.


Running JavaScript



Running JavaScript
• Interpreter – Runs code, not fast



Running JavaScript
• Basic JIT – Simple, untyped compiler



Running JavaScript
• Trace Compiler - Typed compiler
for traces (low latency, often fast).



Running JavaScript
• Trace Compiler - Typed compiler
for traces (low latency, often fast).
• Heavy-Duty JIT – Typed compiler for
whole methods (high latency,
always fast).



Interpreter

• Good for code that runs once
• Giant switch loop
• Handles all edge cases of JS
semantics



Interpreter
while (true) {
switch (*pc) {
case OP_ADD:
...
case OP_SUB:
...
case OP_RETURN:
...
}
pc++;
}



Interpreter
case OP_ADD: {
Value lhs = POP();
Value rhs = POP();
Value result;
if (lhs.isInt32() && rhs.isInt32()) {
int left = rhs.toInt32();
int right = rhs.toInt32();
if (AddOverﬂows(left, right, left + right))
result.setInt32(left + right);
else
result.setNumber(double(left) + double(right));
} else if (lhs.isString() || rhs.isString()) {
String *left = ValueToString(lhs);
String *right = ValueToString(rhs);
String *r = Concatenate(left, right);
result.setString(r);
} else {
double left = ValueToNumber(lhs);
double right = ValueToNumber(rhs);
result.setDouble(left + right);
}
PUSH(result);
break;



Interpreter



Interpreter

• Very slow!
• Lots of opcode and type dispatch
• Lots of interpreter stack traffic



Interpreter

• Very slow!
• Lots of opcode and type dispatch
• Lots of interpreter stack traffic
• Just-in-time compilation solves
both



Just In Time



Just In Time
• Compilation must be very fast
• Can’t introduce noticeable pauses



Just In Time
• Compilation must be very fast
• Can’t introduce noticeable pauses
• People care about memory use
• Can’t JIT everything
• Can’t create bloated code
• May have to discard code at any
time


Basic JIT



Basic JIT
• JägerMonkey in Firefox 4



Basic JIT

• Every opcode has a hand-coded
template of assembly (registers left
blank)



Basic JIT

• Every opcode has a hand-coded
template of assembly (registers left
blank)

• Method at a time:

• Single pass through bytecode stream!

• Compiler uses assembly templates
corresponding to each opcode


Bytecode
GETARG 0 ; fetch x
function Add(x, y) {
GETARG 1 ; fetch y
return x + y; ADD
}
RETURN



Assembling ADD



Assembling ADD

• Inlining that huge chunk for every
ADD would be very slow



Assembling ADD

• Inlining that huge chunk for every
ADD would be very slow
• Observation:
• Some input types much more
common than others



Integer Math – Common
var j = 0;
for (i = 0; i < 10000; i++) {
j += i;
}

Weird Stuff – Rare!
var j = 12.3;
for (i = 0; i < 10000; i++) {
j += new Object() + i.toString();
}



Assembling ADD
• Only generate code for the easiest
and most common cases
• Large design space
• Can consider integers common, or
• Integers and doubles, or
• Anything!


Basic JIT - ADD
if (arg0.type != INT32)
goto slow_add;
goto slow_add;



Basic JIT - ADD
goto slow_add;
goto slow_add;
R0 = arg0.data
R1 = arg1.data



Basic JIT - ADD
goto slow_add;
goto slow_add; Greedy
R0 = arg0.data
R1 = arg1.data Register
Allocator



Basic JIT - ADD
goto slow_add;
goto slow_add;
R0 = arg0.data;
R1 = arg1.data;
R2 = R0 + R1;
if (OVERFLOWED)
goto slow_add;



Slow Paths

slow_add:
Value result = runtime::Add(arg0, arg1);



Inline Out-of-line
goto slow_add; slow_add:
if (arg1.type != INT32) Value result = Interpreter::Add(arg0, arg1);
R2 = result.data;
goto slow_add; goto rejoin;
R0 = arg0.data;
R1 = arg1.data;
R2 = R0 + R1;
if (OVERFLOWED)
goto slow_add;
rejoin:



Rejoining
Inline Out-of-line
goto slow_add; slow_add:
if (arg1.type != INT32) Value result = runtime::Add(arg0, arg1);
goto slow_add; R2 = result.data;
R3 = result.type;
R0 = arg0.data; goto rejoin;
R1 = arg1.data;
R2 = R0 + R1;
if (OVERFLOWED)
goto slow_add;
R3 = TYPE_INT32;
rejoin:



Final Code
Inline Out-of-line
goto slow_add;
if (arg1.type != INT32) slow_add:
Value result = Interpreter::Add(arg0, arg1);
goto slow_add; R2 = result.data;
R0 = arg0.data; R3 = result.type;
R1 = arg1.data; goto rejoin;
R2 = R0 + R1;
if (OVERFLOWED)
goto slow_add;
R3 = TYPE_INT32;
rejoin:
return Value(R3, R2);



Observations



Observations
• Even though we have fast paths, no
type information can ﬂow in
between opcodes
• Cannot assume result of ADD is
integer
• Means more branches



Observations
• Even though we have fast paths, no
type information can ﬂow in
between opcodes
• Cannot assume result of ADD is
integer
• Means more branches
• Types increase register pressure


Basic JIT – Object Access
function f(x) {
return x.y;
}

• x.y is a dictionary search!

• How can we create a fast-path?

• We could try to cache the lookup, but

• We want it to work for >1 objects



Object Access



Object Access

• Observation
• Usually, objects ﬂowing through
an access site look the same



Object Access

• Observation
• Usually, objects ﬂowing through
an access site look the same
• If we knew an object’s layout, we
could bypass the dictionary
lookup



Object Layout

var obj = { x: 50,
y: 100,
z: 20
};



Object Layout



Object Layout
JSObject
Shape *shape;

Value *slots;



Object Layout
Shape JSObject
Property Name Slot Number
Shape *shape;

x 0
Value *slots;
y 1

z 2



Object Layout
Shape JSObject
Shape *shape;
0 (Int32, 50)
x 0
Value *slots; 1 (Int32, 100)
y 1
2 (Int32, 20)

z 2



Object Layout
var obj = { x: 50,
y: 100,
z: 20
};
…
var obj2 = { x: 78,
y: 93,
z: 600
};


Object Layout
Shape JSObject
Property Name Slot Number 0 (Int32, 50)
Shape *shape;
x 0 1 (Int32, 100)
Value *slots;
2 (Int32, 20)
y 1

z 2



Object Layout
Shape JSObject
Shape *shape;
x 0 1 (Int32, 100)
Value *slots;
2 (Int32, 20)
y 1

z 2 JSObject
Shape *shape;

Value *slots;



Object Layout
Shape JSObject
Shape *shape;
x 0 1 (Int32, 100)
Value *slots;
2 (Int32, 20)
y 1

z 2 JSObject
0 (Int32, 78)
Shape *shape;
1 (Int32, 93)
Value *slots;
2 (Int32, 600)



Familiar Problems



Familiar Problems

• We don’t know an object’s shape
during JIT compilation



Familiar Problems

• ... Or even that a property access
receives an object!



Familiar Problems

• ... Or even that a property access
receives an object!
• Solution: leave code “blank,” lazily
generate it later



Inline Caches
function f(x) {
return x.y;
}



Inline Caches
• Start as normal, guarding on type and
loading data
if (arg0.type != OBJECT)
goto slow_property;
JSObject *obj = arg0.data;



Inline Caches
• No information yet: leave blank (nops).
goto slow_property;

goto property_ic;


Property ICs
function f(x) {
return x.y;
}

f({x: 5, y: 10, z: 30});



Property ICs
Shape S1 JSObject
Property Name Slot Number Shape
*shape; 0 (Int32, 5)
x 0
Value *slots; 1 (Int32, 10)
y 1
2 (Int32, 30)

z 2



Property ICs
Shape S1

x 0

y 1

z 2



Property ICs
Shape S1

x 0

y 1
z 2



Inline Caches
• Shape = S , slot is 1
1

goto slow_property;

goto property_ic;


Inline Caches
• Shape = SHAPE , slot is 1 1

goto slow_property;
if (obj->shape != SHAPE1)
goto property_ic;
R0 = obj->slots[1].type;
R1 = obj->slots[1].data;



Polymorphism

• What happens if two different
shapes pass through a property
access?



Polymorphism
function f(x) {
return x.y;
}
f({ x: 5, y: 10, z: 30});
f({ y: 40});

• What happens if two different
shapes pass through a property
access?



Polymorphism
function f(x) {
return x.y;
}
f({ x: 5, y: 10, z: 30});
f({ y: 40});



Polymorphism
Main Method

goto slow_path;
if (obj->shape != SHAPE1)
goto property_ic;
rejoin:



Polymorphism
Main Method Generated Stub
stub:
if (arg0.type != OBJECT) if (obj->shape != SHAPE2)
goto slow_path; goto property_ic;
JSObject *obj = arg0.data; R0 = obj->slots[0].type;
if (obj->shape != SHAPE0) R1 = obj->slots[0].data;
goto property_ic; goto rejoin;
rejoin:



Polymorphism
Main Method Generated Stub
stub:
if (arg0.type != OBJECT) if (obj->shape != SHAPE2)
goto slow_path; goto property_ic;
JSObject *obj = arg0.data; R0 = obj->slots[0].type;
if (obj->shape != SHAPE1) R1 = obj->slots[0].data;
goto stub; goto rejoin;
rejoin:



Chain of Stubs
if (obj->shape == S1) {
result = obj->slots[0];
} else {
} else {
} else {
} else {
goto property_ic;
}
}
}
}



Code Memory
• Generated code is patched from
inside the method
• Self-modifying, but single
threaded

• Code memory is always rwx
• Concerned about protection-
ﬂipping expense



Basic JIT Summary



Basic JIT Summary

• Generates simple code to handle
common cases



Basic JIT Summary

common cases
• Inline caches adapt code based on
runtime observations



Basic JIT Summary

common cases
• Inline caches adapt code based on
runtime observations
• Lots of guards, poor type
information



Optimizing Harder



Optimizing Harder
• Single pass too limited: we want to
perform whole-method
optimizations



Optimizing Harder
optimizations
• We could generate an IR, but
without type information...



Optimizing Harder
optimizations
• We could generate an IR, but
without type information...
• Slow paths prevent most
optimizations.



Code Motion?
function Add(x, n) {
var sum = 0;
for (var i = 0; i < n; i++)
sum += x + n;
return sum;
}

The addition looks loop invariant.
Can we hoist it?


Code Motion?
function Add(x, n) {
var sum = 0;
var temp0 = x + n;
for (var i = 0; i < n; i++)
sum += temp0;
return sum;
}

Let’s try it.



Wrong Result
var global = 0;
var obj = {
valueOf: function () {
return ++global;
}
}
Add(obj, 10);



Wrong Result
var global = 0;
var obj = {
return ++global;
}
}
Add(obj, 10);

• Original code returns 155



Wrong Result
var global = 0;
var obj = {
return ++global;
}
}
Add(obj, 10);

• Original code returns 155
• Hoisted version returns 110!


Idempotency
• Untyped operations are usually not
provably idempotent
• Slow paths are re-entrant, can
have observable side effects
• This prevents code motion,
redundancy elimination
• Just ask the Chakra team...


Ideal Scenario



Ideal Scenario
• Actual knowledge about types!



Ideal Scenario
• Remove slow paths



Ideal Scenario
• Record and execute typed traces!
(TraceMonkey)



Ideal Scenario
• Record and execute typed traces!
(TraceMonkey)
• Or eve perform whole-method
optimizations



Heavy Duty JITs



Heavy Duty JITs
• Make optimistic guesses about types



Heavy Duty JITs
• Guesses must be informed
• Don’t want to waste time compiling
code that can’t or won’t run



Heavy Duty JITs
• Using type inference or runtime
proﬁling



Heavy Duty JITs
• Using type inference or runtime
proﬁling
• Generate an IR, perform textbook
compiler optimizations


Optimism Pays Off

• People naturally write code as if it
were typed
• Variables and object ﬁelds that
change types are rare



IonMonkey



IonMonkey

• Work in progress



IonMonkey

• Constructs high and low-level IRs



IonMonkey

• Applies type information using
runtime feedback



IonMonkey

• Applies type information using
runtime feedback
• Inlining, GVN, LICM, LSRA


GETARG 0 ; fetch x
function Add(x, y) { GETARG 1 ; fetch y
}
return x + y + x; ADD
GETARG 0 ; fetch x
ADD
RETURN



Build SSA
GETARG 0 ; fetch x v0 = arg0
GETARG 1 ; fetch y v1 = arg1
ADD
GETARG 0 ; fetch x
ADD
RETURN



Type Oracle

• Need a mechanism to inform
compiler about likely types
• Type Oracle: given program counter,
returns types for inputs and outputs
• May use any data source – runtime
proﬁling, type inference, etc



Type Oracle

• For this example, assume the type
oracle returns “integer” for the
output and both inputs to all ADD
operations



Build SSA
ADD
v2 = iadd(v0, v1)
GETARG 0 ; fetch x
ADD
RETURN



Build SSA
ADD
v2 = iadd(v0, v1)
GETARG 0 ; fetch x
ADD v3 = iadd(v2, v0)
RETURN



Build SSA
ADD
v2 = iadd(v0, v1)
GETARG 0 ; fetch x
ADD v3 = iadd(v2, v0)
RETURN v4 = return(v3)



SSA (Intermediate)

v0 = arg0
v1 = arg1
v2 = iadd(v0, v1)
v3 = iadd(v2, v0)
v4 = return(v3)



SSA (Intermediate)

Untyped v0 = arg0
v1 = arg1
v2 = iadd(v0, v1)
v3 = iadd(v2, v0)
v4 = return(v3)



SSA (Intermediate)

Untyped v0 = arg0
v1 = arg1
v2 = iadd(v0, v1)
Typed
v3 = iadd(v2, v0)
v4 = return(v3)



Intermediate SSA



Intermediate SSA
• SSA does not type check



Intermediate SSA
• SSA does not type check
• Type analysis:
• Makes sure SSA inputs have
correct type
• Inserts conversions, value
decoding



Unoptimized SSA
v0 = arg0
v1 = arg1
v2 = unbox(v0, INT32)
v4 = iadd(v2, v3)
v6 = iadd(v4, v5)
v7 = return(v6)



Optimization
v0 = arg0
v1 = arg1
v4 = iadd(v2, v3)
v6 = iadd(v4, v5)
v7 = return(v6)



Optimized SSA
v0 = arg0
v1 = arg1
v4 = iadd(v2, v3)
v5 = iadd(v4, v2)
v6 = return(v5)



Register Allocation
• Linear Scan Register Allocation
• Based on Christian Wimmer’s work
• Linear Scan Register Allocation for the Java HotSpot™ Client Compiler.
Master's thesis, Institute for System Software, Johannes Kepler University
Linz, 2004

• Linear Scan Register Allocation on SSA Form. In Proceedings of the
International Symposium on Code Generation and Optimization, pages
170–179. ACM Press, 2010.

• Same algorithm used in Hotspot JVM


Allocate Registers

0: stack arg0
1: stack arg1
2: r1 unbox(0, INT32)
4: r0 iadd(2, 3)
5: r0 iadd(4, 2)
6: r0 return(5)



Code Generation
SSA
0: stack arg0
1: stack arg1
4: r0 iadd(2, 3)
5: r0 iadd(4, 2)
6: r0 return(5)



Code Generation
SSA Native Code
0: stack arg0
1: stack arg1
goto BAILOUT;
r1 = arg0.data;
4: r0 iadd(2, 3)
5: r0 iadd(4, 2)
6: r0 return(5)



Code Generation
SSA Native Code
0: stack arg0 if (arg0.type != INT32)
1: stack arg1 goto BAILOUT;
2: r1 unbox(0, INT32) r1 = arg0.data;
3: r0 unbox(1, INT32) if (arg1.type != INT32)
4: r0 iadd(2, 3) goto BAILOUT;
5: r0 iadd(4, 2) r0 = arg1.data;
6: r0 return(5)



Code Generation
SSA Native Code
6: r0 return(5) r0 = r0 + r1;
if (OVERFLOWED)
goto BAILOUT;



Code Generation
SSA Native Code
6: r0 return(5) r0 = r0 + r1;
if (OVERFLOWED)
goto BAILOUT;
r0 = r0 + r1;
if (OVERFLOWED)
goto BAILOUT;



Code Generation
SSA Native Code
6: r0 return(4) r0 = r0 + r1;
if (OVERFLOWED)
goto BAILOUT;
r0 = r0 + r1;
if (OVERFLOWED)
goto BAILOUT;
return r0;



Generated Code
goto BAILOUT;
r0 = arg0.data;
goto BAILOUT;
r1 = arg1.data;
r0 = r0 + r1;
if (OVERFLOWED)
goto BAILOUT;
r0 = r0 + r1;
if (OVERFLOWED)
goto BAILOUT;
return r0;



Generated Code
goto BAILOUT; • Bailout exits JIT
r0 = arg0.data;
goto BAILOUT;
r1 = arg1.data;
r0 = r0 + r1;
if (OVERFLOWED)
goto BAILOUT;
r0 = r0 + r1;
if (OVERFLOWED)
goto BAILOUT;
return r0;



Generated Code
goto BAILOUT; • Bailout exits JIT
r0 = arg0.data;
• May recompile function
goto BAILOUT;
r1 = arg1.data;
r0 = r0 + r1;
if (OVERFLOWED)
goto BAILOUT;
r0 = r0 + r1;
if (OVERFLOWED)
goto BAILOUT;
return r0;



Guards Still Needed

• Object shapes for reading properties
• Types of…
• Arguments
• Values read from the heap
• Values returned from C++


Guards Still Needed

• Math
• Integer Overﬂow
• Divide by Zero
• Multiply by -0
• NaN is falsey in JS, truthy in ISAs


Heavy Duty JITs
• Full type speculation - no slow
paths
• Can move and eliminate code



Heavy Duty JITs
paths
• If speculation fails, method is
recompiled or deoptimized



Heavy Duty JITs
paths
• If speculation fails, method is
recompiled or deoptimized
• Can still use techniques like inline
caching!



To Inﬁnity, and Beyond



• Heavy-Duty JIT example has four guards:




• Two type checks




• Two type checks

• Two overﬂow checks




• Two type checks


• Better than Basic JIT, but we can do
better




• Two type checks


better

• Interval analysis can remove overﬂow
checks




• Two type checks


better

• Interval analysis can remove overﬂow
checks

• Type Inference!


Type Inference



Type Inference
• Whole program analysis to
determine types of variables



Type Inference
• Hybrid: both static and dynamic



Type Inference
• Hybrid: both static and dynamic
• Replaces checks in JIT with checks
in virtual machine
• If VM breaks an assumption held
in any JIT code, that JIT code is
discarded


Conclusions
• The web needs JavaScript to be fast
• Untyped, highly dynamic nature
makes this challenging
• Value boxing has different tradeoffs
on different ISAs
• GC needs to be fast. Lots of room
for future research.



Conclusions

• JITs getting more powerful
• Type specialization is key
• Still need checks and special cases
on many operations



Onwards

• The web is just getting warmed up
• Fast JavaScript execution and new
platform capabilities are pushing
the boundaries of whats possible
inside a web browser.



pdf.js



pdf.js
• 12k lines of JS code
• C++ poppler library closer to
200k of code
• Excellent performance (GPU
accelerated canvas API)
• Unbeatable security story


dom.js



dom.js
• The DOM is the OS / API of the web
platform
• Traditionally implemented in C++.
• Calling into the DOM requires
expensive wrapping.
• C++ code is re-entrant.
Nightmare for any analysis.



dom.js
• dom.js re-implements the DOM in
JavaScript
• Several new language features are
being standardized for JS to make
this possible (Proxies, WeakMaps)
• Massive speedup for some
operations (by using JS vs C++!)



Why should you care?
• The web is displacing proprietary
Operating Systems as the next
application platform
• A lot of academic research is still
focused on Java/C++/etc. Those are
obsolete technologies as far as the
web is concerned



Research Opportunities

• JavaScript still 1.5-10x behind C++
in some cases
• Many unknowns in the area of GC,
Debugging, Proﬁling, Static Analysis



Next Up: Boot to Web



Want to get involved?
• The web is open technology. Anyone
can help extend and improve it
• Several Universities participate in the
JavaScript standards group (TC39), for
example
• Tom Van Cutsem’s JavaScript Proxies
work already available to 300mil
people. Soon also in Chrome



Questions?



High Performance JavaScript

More Related Content

Similar to High Performance JavaScript (20)

More from greenwop (9)

Recently uploaded (20)

High Performance JavaScript