V8 by example: A journey through the compilation pipeline by Ujjwas Sharma at FrontCon 2019

@ryzokuken
V8 by Example
A journey through the compilation pipeline
1

@ryzokuken
Ujjwal Sharma (@ryzokuken)
● Node.js – Core Collaborator
● Electron.js – Maintainer
● Contribute to the JS/Node.js ecosystem
○ V8
○ TC39
○ libuv
○ …
● Student
● Google Summer of Code
● Speaker
2

@ryzokuken@ryzokuken
What is V8?
3

How does V8 work?
5

@ryzokuken@ryzokuken7
Source
Parser

Source
Parser

Source
IIFE?

Source
IIFE?
Eager

Source
IIFE? Lazy
Eager

Source
IIFE?
* Eventually
Eager
Lazy

Source
IIFE?
Eager
Lazy
AST +
Scopes

Source
Parser
AST +
Scopes

Source
Parser
AST +
Scopes
Ignition

Source
Parser
AST +
Scopes
Ignition Bytecode

But interpreters are so slow!
Idea: Let’s not be slow.
Let’s use a JIT compiler.

Source
Parser
AST +
Scopes
Ignition Bytecode
Turbofan
+ profiling data
OPTIMIZE!

Source
Parser
AST +
Scopes
Ignition Bytecode
Turbofan
Optimized
Code
DEOPTIMIZE!

Source
Parser
AST +
Scopes
Ignition Bytecode
Turbofan
Optimized
Code

How you feel about everything.
Let’s take a couple steps back.23

How does V8 work?
24

How does V8 work?
a compiler
25

Source
Code
Parser
Abstract
Syntax
Tree
Assembler
Machine
Code (R)
Compiler
Assembly
Program
Linker
Machine
Code (T)
26

Is it simple enough yet?
27

Source
Code
Parser
Abstract
Syntax
Tree
Assembler
Machine
Code (R)
Compiler
Assembly
Program
Linker
Machine
Code (T)
28

Source
Code
Parser
Abstract
Syntax
Tree
Compiler
Machine
Code (T)
29

BAD NEWS: V8 isn’t this simple

Because ECMAScript is slow by default, that’s why.
31

Idea: Let’s not be slow.
BUT HOW?
Speculative Optimization
32

But wait…
What even is
Speculative Optimization?
33

[spek-yuh-ley-tiv, -luh-tiv][op-tuh-muh-zey-shuh n]
Noun.
Guessing what is about to happen based
on what has happened.
34

[spek-yuh-ley-tiv, -luh-tiv][op-tuh-muh-zey-shuh n]
Noun.
Guessing what is about to happen based
on what has happened.
Making assumptions about possible
future inputs based on previous inputs.
35

Top three reasons why a JavaScript
function might need optimization:
1. Dynamic Types
2. Dynamic Types
3. Dynamic Types
Alright, but how does it help?
36

Source
Code
Parser
Abstract
Syntax
Tree
Compiler
Machine
Code (T)
37

Source
Code
Parser
Abstract
Syntax
Tree
1. Baseline Interpreter
2. Optimizing Compiler
Machine
Code (T)
38

AST
Baseline
Interpreter
Optimizing
Compiler
Bytecode
Optimized Code
optimize
deoptimize
39

Compiler
Baseline
Interpreter
Optimizing
Compiler
40

AST
Baseline
Interpreter
Optimizing
Compiler
Bytecode
Optimized Code
optimize
deoptimize
41

AST
Bytecode
Optimized Code
optimize
deoptimize
42

Okay, that’s great.
But how does it even work?
Let’s consider an example.

function add(x, y) {
return x + y;
}
console.log(add(1, 2));

Not too intuitive?
I’ve got you covered, fam.
Let’s see how the Abstract Syntax Tree actually looks.

[generating bytecode for function: add]
--- AST ---
FUNC at 12
. KIND 0
. SUSPEND COUNT 0
. NAME "add"
. PARAMS
. . VAR (...) (mode = VAR) "x"
. . VAR (...) (mode = VAR) "y"
. RETURN at 22
. . ADD at 31
. . . VAR PROXY parameter[0] (...) (mode = VAR) "x"
. . . VAR PROXY parameter[1] (...) (mode = VAR) "y"

--- AST ---
FUNC at 12
. KIND 0
. SUSPEND COUNT 0
. NAME "add"
. PARAMS
. . VAR (...) (mode = VAR) "x"
. . VAR (...) (mode = VAR) "y"
. RETURN at 22
. . ADD at 31
FUNC

--- AST ---
FUNC at 12
. KIND 0
. SUSPEND COUNT 0
. NAME "add"
. PARAMS
. . VAR (...) (mode = VAR) "x"
. . VAR (...) (mode = VAR) "y"
. RETURN at 22
. . ADD at 31
FUNC
NAME “add”

--- AST ---
FUNC at 12
. KIND 0
. SUSPEND COUNT 0
. NAME "add"
. PARAMS
. . VAR (...) (mode = VAR) "x"
. . VAR (...) (mode = VAR) "y"
. RETURN at 22
. . ADD at 31
FUNC
NAME “add” PARAMS

--- AST ---
FUNC at 12
. KIND 0
. SUSPEND COUNT 0
. NAME "add"
. PARAMS
. . VAR (...) (mode = VAR) "x"
. . VAR (...) (mode = VAR) "y"
. RETURN at 22
. . ADD at 31
FUNC
VAR “x”

--- AST ---
FUNC at 12
. KIND 0
. SUSPEND COUNT 0
. NAME "add"
. PARAMS
. . VAR (...) (mode = VAR) "x"
. . VAR (...) (mode = VAR) "y"
. RETURN at 22
. . ADD at 31
FUNC
VAR “x” VAR “y”

--- AST ---
FUNC at 12
. KIND 0
. SUSPEND COUNT 0
. NAME "add"
. PARAMS
. . VAR (...) (mode = VAR) "x"
. . VAR (...) (mode = VAR) "y"
. RETURN at 22
. . ADD at 31
FUNC
NAME “add” PARAMS RETURN
VAR “x” VAR “y”

--- AST ---
FUNC at 12
. KIND 0
. SUSPEND COUNT 0
. NAME "add"
. PARAMS
. . VAR (...) (mode = VAR) "x"
. . VAR (...) (mode = VAR) "y"
. RETURN at 22
. . ADD at 31
FUNC
VAR “x” VAR “y” ADD

--- AST ---
FUNC at 12
. KIND 0
. SUSPEND COUNT 0
. NAME "add"
. PARAMS
. . VAR (...) (mode = VAR) "x"
. . VAR (...) (mode = VAR) "y"
. RETURN at 22
. . ADD at 31
FUNC
PROXY “x”

--- AST ---
FUNC at 12
. KIND 0
. SUSPEND COUNT 0
. NAME "add"
. PARAMS
. . VAR (...) (mode = VAR) "x"
. . VAR (...) (mode = VAR) "y"
. RETURN at 22
. . ADD at 31
FUNC
PROXY “x” PROXY “y”

Scope Resolution
FUNC
PROXY “y”PROXY “x”

Let’s step through the bytecode.
Hope you like Assembly.
Once this is done, we can generate bytecode.

[generated bytecode for function: add]
Parameter count 3
Frame size 0
12 E> 0x38d5f59df42 @ 0 : a5 StackCheck
22 S> 0x38d5f59df43 @ 1 : 25 02 Ldar a1
31 E> 0x38d5f59df45 @ 3 : 34 03 00 Add a0, [0]
35 S> 0x38d5f59df48 @ 6 : a9 Return
Constant pool (size = 0)
Handler Table (size = 0)

Parameter count 3
Frame size 0
22 S> 0x38d5f59df43 @ 1 : 25 02 Ldar a1
31 E> 0x38d5f59df45 @ 3 : 34 03 00 Add a0, [0]
35 S> 0x38d5f59df48 @ 6 : a9 Return

StackCheck
Ldar a1
Add a0, [0]
Return

Two important things happen here.
1. Addition: It’s complicated.
2. Profiling: Feedback Vectors help.

StackCheck
Ldar a1
Add a0, [0]
Return

What about that Speculative Optimization thingie he
was talking about earlier?
Now that we finally have the baseline code running,
let’s put that profiling data to good use.
But wait...

Oh, also, remember that time when
I said addition in JavaScript was
complicated?

Let me break it down for you.

Number
String
Object

Remember Feedback Vectors?
Let’s see how they really look to see how it all works.
Awesome! But how do we make that assumption?

return x + y;
}

return x + y;
}
%DebugPrint(add);

...
- feedback vector: 0x18bc7711df89: [FeedbackVector] in OldSpace
- map: 0x18bc38c00bc1 <Map>
- length: 1
- shared function info: 0x18bc7711dc59 <SharedFunctionInfo add>
- optimized code/marker: OptimizationMarker::kNone
- invocation count: 1
- profiler ticks: 0
- slot #0 BinaryOp BinaryOp:SignedSmall {
[0]: 1
}
...

return x + y;
}
%DebugPrint(add);

return x + y;
}
console.log(add(1.1, 2.2));
%DebugPrint(add);

...
- feedback vector: 0xcbd92d1dfe1: [FeedbackVector] in OldSpace
- map: 0x0cbd4f880bc1 <Map>
- length: 1
- shared function info: 0x0cbd92d1dc59 <SharedFunctionInfo add>
- optimized code/marker: OptimizationMarker::kNone
- invocation count: 2
- profiler ticks: 0
- slot #0 BinaryOp BinaryOp:Number {
[0]: 7
}
...

Question: Is there a method to all this?
Answer: Yes, it is called the Feedback Lattice.

None
SignedSmall
Number
BigIntString
NumberOrOddball
Any

This data in the Feedback Vectors is used to finally optimize
your code once a function is hot.
When is a function “hot”?
Let’s see what actually happens by explicitly triggering
optimization.

return x + y;
}
add(1, 2);

return x + y;
}
add(1, 2); // Warm up with SignedSmall feedback.
%OptimizeFunctionOnNextCall(add);
add(1, 2); // Optimize and run generated code.

Question: What did we just do?

Let’s see the optimized code generated by passing the --
print-opt-code flag to d8.

leaq rbx,[rip+0xfffffff9]
movq rbx,[rcx-0x20]
testb [rbx+0xf],0x1
jz 0x198104882dfb <+0x3b>
movq r10,0x10efbfde0 (CompileLazyDeoptimizedCode)
jmp r10
push rbp
movq rbp,rsp
push rsi
push rdi
cmpq rsp,[r13+0x11e8] (root (stack_limit))
jna 0x198104882e55 <+0x95>
movq rdx,[rbp+0x18]
testb rdx,0x1
jnz 0x198104882e7b <+0xbb>
movq rcx,[rbp+0x10]
testb rcx,0x1
jnz 0x198104882e87 <+0xc7>
movq rdi,rcx
shrq rdi, 32
movq r8,rdx
shrq r8, 32
addl rdi,r8
jo 0x198104882e93 <+0xd3>
shlq rdi, 32
movq rax,rdi
movq rsp,rbp
pop rbp
ret 0x18

movq rbx,[rcx-0x20]
testb [rbx+0xf],0x1
jz 0x198104882dfb <+0x3b>
jmp r10
push rbp
movq rbp,rsp
push rsi
push rdi
jna 0x198104882e55 <+0x95>
movq rdx,[rbp+0x18]
testb rdx,0x1
jnz 0x198104882e7b <+0xbb>
movq rcx,[rbp+0x10]
testb rcx,0x1
jnz 0x198104882e87 <+0xc7>
movq rdi,rcx
shrq rdi, 32
movq r8,rdx
shrq r8, 32
addl rdi,r8
jo 0x198104882e93 <+0xd3>
shlq rdi, 32
movq rax,rdi
movq rsp,rbp
pop rbp
ret 0x18
Prologue

movq rbx,[rcx-0x20]
testb [rbx+0xf],0x1
jz 0x198104882dfb <+0x3b>
jmp r10
push rbp
movq rbp,rsp
push rsi
push rdi
jna 0x198104882e55 <+0x95>
movq rdx,[rbp+0x18]
testb rdx,0x1
jnz 0x198104882e7b <+0xbb>
movq rcx,[rbp+0x10]
testb rcx,0x1
jnz 0x198104882e87 <+0xc7>
movq rdi,rcx
shrq rdi, 32
movq r8,rdx
shrq r8, 32
addl rdi,r8
jo 0x198104882e93 <+0xd3>
shlq rdi, 32
movq rax,rdi
movq rsp,rbp
pop rbp
ret 0x18
Check x is Smi

movq rbx,[rcx-0x20]
testb [rbx+0xf],0x1
jz 0x198104882dfb <+0x3b>
jmp r10
push rbp
movq rbp,rsp
push rsi
push rdi
jna 0x198104882e55 <+0x95>
movq rdx,[rbp+0x18]
testb rdx,0x1
jnz 0x198104882e7b <+0xbb>
movq rcx,[rbp+0x10]
testb rcx,0x1
jnz 0x198104882e87 <+0xc7>
movq rdi,rcx
shrq rdi, 32
movq r8,rdx
shrq r8, 32
addl rdi,r8
jo 0x198104882e93 <+0xd3>
shlq rdi, 32
movq rax,rdi
movq rsp,rbp
pop rbp
ret 0x18
Check y is Smi

movq rbx,[rcx-0x20]
testb [rbx+0xf],0x1
jz 0x198104882dfb <+0x3b>
jmp r10
push rbp
movq rbp,rsp
push rsi
push rdi
jna 0x198104882e55 <+0x95>
movq rdx,[rbp+0x18]
testb rdx,0x1
jnz 0x198104882e7b <+0xbb>
movq rcx,[rbp+0x10]
testb rcx,0x1
jnz 0x198104882e87 <+0xc7>
movq rdi,rcx
shrq rdi, 32
movq r8,rdx
shrq r8, 32
addl rdi,r8
jo 0x198104882e93 <+0xd3>
shlq rdi, 32
movq rax,rdi
movq rsp,rbp
pop rbp
ret 0x18
Smi → Word32 (x)

movq rbx,[rcx-0x20]
testb [rbx+0xf],0x1
jz 0x198104882dfb <+0x3b>
jmp r10
push rbp
movq rbp,rsp
push rsi
push rdi
jna 0x198104882e55 <+0x95>
movq rdx,[rbp+0x18]
testb rdx,0x1
jnz 0x198104882e7b <+0xbb>
movq rcx,[rbp+0x10]
testb rcx,0x1
jnz 0x198104882e87 <+0xc7>
movq rdi,rcx
shrq rdi, 32
movq r8,rdx
shrq r8, 32
addl rdi,r8
jo 0x198104882e93 <+0xd3>
shlq rdi, 32
movq rax,rdi
movq rsp,rbp
pop rbp
ret 0x18
Smi → Word32 (y)

movq rbx,[rcx-0x20]
testb [rbx+0xf],0x1
jz 0x198104882dfb <+0x3b>
jmp r10
push rbp
movq rbp,rsp
push rsi
push rdi
jna 0x198104882e55 <+0x95>
movq rdx,[rbp+0x18]
testb rdx,0x1
jnz 0x198104882e7b <+0xbb>
movq rcx,[rbp+0x10]
testb rcx,0x1
jnz 0x198104882e87 <+0xc7>
movq rdi,rcx
shrq rdi, 32
movq r8,rdx
shrq r8, 32
addl rdi,r8
jo 0x198104882e93 <+0xd3>
shlq rdi, 32
movq rax,rdi
movq rsp,rbp
pop rbp
ret 0x18
Add x and y
Overflow Check

movq rbx,[rcx-0x20]
testb [rbx+0xf],0x1
jz 0x198104882dfb <+0x3b>
jmp r10
push rbp
movq rbp,rsp
push rsi
push rdi
jna 0x198104882e55 <+0x95>
movq rdx,[rbp+0x18]
testb rdx,0x1
jnz 0x198104882e7b <+0xbb>
movq rcx,[rbp+0x10]
testb rcx,0x1
jnz 0x198104882e87 <+0xc7>
movq rdi,rcx
shrq rdi, 32
movq r8,rdx
shrq r8, 32
addl rdi,r8
jo 0x198104882e93 <+0xd3>
shlq rdi, 32
movq rax,rdi
movq rsp,rbp
pop rbp
ret 0x18
Result to Smi

movq rbx,[rcx-0x20]
testb [rbx+0xf],0x1
jz 0x198104882dfb <+0x3b>
jmp r10
push rbp
movq rbp,rsp
push rsi
push rdi
jna 0x198104882e55 <+0x95>
movq rdx,[rbp+0x18]
testb rdx,0x1
jnz 0x198104882e7b <+0xbb>
movq rcx,[rbp+0x10]
testb rcx,0x1
jnz 0x198104882e87 <+0xc7>
movq rdi,rcx
shrq rdi, 32
movq r8,rdx
shrq r8, 32
addl rdi,r8
jo 0x198104882e93 <+0xd3>
shlq rdi, 32
movq rax,rdi
movq rsp,rbp
pop rbp
ret 0x18
Epilogue

Now, let’s try something fun.

return x + y;
}

return x + y;
}
add(1.1, 2.2) // DEOPTIMIZE!

Note: I’m obviously kidding.
Deoptimization is no laughing matter.

Let’s see how the code is actually deoptimized by passing the
--trace-deopt flag to d8.

[deoptimizing (DEOPT eager): begin 0x08d97929dbc1 <JSFunction add (sfi = 0x8d97929d999)> (opt #0)
@0, FP to SP delta: 24, caller sp: 0x7ffee7bee248]
;;; deoptimize at <add.js:2:12>, not a Smi
reading input frame add => bytecode_offset=0, args=3, height=1, retval=0(#0); inputs:
0: 0x08d97929dbc1 ; [fp - 16] 0x08d97929dbc1 <JSFunction add (sfi = 0x8d97929d999)>
1: 0x08d9c6b81521 ; [fp + 32] 0x08d9c6b81521 <JSGlobal Object>
2: 0x08d97929da31 ; rdx 0x08d97929da31 <HeapNumber 1.1>
3: 0x08d97929da41 ; [fp + 16] 0x08d97929da41 <HeapNumber 2.2>
4: 0x08d979281749 ; [fp - 24] 0x08d979281749 <NativeContext[247]>
5: 0x08d92b080e19 ; (literal 2) 0x08d92b080e19 <Odd Oddball: optimized_out>
translating interpreted frame add => bytecode_offset=0, height=8
0x7ffee7bee240: [top + 72] <- 0x08d9c6b81521 <JSGlobal Object> ; stack parameter (input #1)
0x7ffee7bee238: [top + 64] <- 0x08d97929da31 <HeapNumber 1.1> ; stack parameter (input #2)
-------------------------
0x7ffee7bee228: [top + 48] <- 0x00010d2881e8 ; caller's pc
0x7ffee7bee220: [top + 40] <- 0x7ffee7bee290 ; caller's fp
0x7ffee7bee218: [top + 32] <- 0x08d979281749 <NativeContext[247]> ; context (input #4)
0x7ffee7bee210: [top + 24] <- 0x08d97929dbc1 <JSFunction add (sfi = 0x8d97929d999)> ;
function (input #0)
0x7ffee7bee208: [top + 16] <- 0x08d97929dca1 <BytecodeArray[7]> ; bytecode array
0x7ffee7bee200: [top + 8] <- 0x003900000000 <Smi 57> ; bytecode offset
-------------------------
0x7ffee7bee1f8: [top + 0] <- 0x08d92b080e19 <Odd Oddball: optimized_out> ; accumulator
(input #5)
[deoptimizing (eager): end 0x08d97929dbc1 <JSFunction add (sfi = 0x8d97929d999)> @0 => node=0,
pc=0x00010d2886c0, caller sp=0x7ffee7bee248, took 1.163 ms]

Don’t worry, I got you.114

-------------------------
function (input #0)
-------------------------
(input #5)

Pro Tip: If you don’t want your code to be slow,
try to stick to certain types.
It makes things easier.

@ryzokuken
Special Thanks
● Benedikt Meurer (@bmeurer)
● Yang Guo (@hashseed)
● Sathya Gunasekaran (@_gsathya)
● Jakob Gruber (@schuay)
● Sigurd Schneider (@sigurdschn)
● ...and everyone else from the V8 team.
● The organizers.
119

Paldies!
120

V8 by example: A journey through the compilation pipeline by Ujjwas Sharma at FrontCon 2019

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to V8 by example: A journey through the compilation pipeline by Ujjwas Sharma at FrontCon 2019

Similar to V8 by example: A journey through the compilation pipeline by Ujjwas Sharma at FrontCon 2019 (20)

More from DevClub_lv

More from DevClub_lv (20)

Recently uploaded

Recently uploaded (20)

V8 by example: A journey through the compilation pipeline by Ujjwas Sharma at FrontCon 2019

Editor's Notes