Moving Node.js and nodec to v8 Ignition

Slide 1

Slide 1 text

Moving Node.js and nodec to Ignition Minqi Pan

Slide 2

Slide 2 text

Chromium #593477 Open Chrome 51 (canary) (1) Load www.facebook.com multiple times in the browser (2) exit the browser, open about:tracing and record all enabled by default categories

Slide 3

Slide 3 text

Chromium #593477 Result: (1) initial load, v8.CompileScript takes 165 ms (2) repeated loads, V8.ParseLazy takes 376 ms

Slide 4

Slide 4 text

Chromium #593477 Why? - Entirely compile eagerly are too costly (Being included in the code cache increases both the footprint on the hard disk and takes longer to serialize and deserialize. let alone the memory…) - So only the toplevel code gets compiled - Functions contained is compiled until the function is actually called - Lazily compiling inner functions still requires a new parsing pass

Slide 5

Slide 5 text

Facebook uses a transpiler to combine individual modules into a single ﬁle. E.g. Chromium #593477

Slide 6

Slide 6 text

Motivation • Memory (major motivator) • Startup Speed • simpler script execution pipeline; reduce jank; make the interchange between V8’s various components more efﬁcient; support ES2015+

Slide 7

Slide 7 text

Old Architecture

Slide 8

Slide 8 text

Multiple Parsing Machine Code

Slide 9

Slide 9 text

might never run again N-level-nested function is parsed N times

Slide 10

Slide 10 text

New Architecture

Slide 11

Slide 11 text

Memory Problem JIT-ed code

Slide 12

Slide 12 text

Memory Optimized

Slide 13

Slide 13 text

Mobile Top 10 Benchmark

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

run-once or non-hot code now stored more compactly in bytecode form

Slide 16

Slide 16 text

Startup Speed Problem actual executing

Slide 17

Slide 17 text

Startup Speed Optimized

Slide 18

Slide 18 text

v8 Bytecode design goals • Concise • … so that Bytecode size have a small memory footprint (machine code generated by V8’s full- codegen compiler is verbose) • … so that we always compile it eagerly • … so that initial startup is faster

Slide 19

Slide 19 text

e.g. accumulator register • implicit register for many bytecodes to hold temporary results • avoiding the need to specify speciﬁc register operands, reduces the size of bytecodes • many JavaScript expressions involve chains of operations

Slide 20

Slide 20 text

Comparing with the others

Slide 21

Slide 21 text

BE & FE differences • FE has limited battery, memory, network resources. • FE usually won’t ship a lot of unused code • BE has big node_modules folder so cost of eagerly compiling all is still huge • BE has mmap, though…mmap works good on a single ﬁle, though…

Slide 22

Slide 22 text

去吧！Node.js Compiler

Slide 23

Slide 23 text

w/ Node.js Compiler • Eagerly compile everything into Bytecode, including node_modules • Put them inside a SquashFS (i.e. your.exe) • Mmap SquashFS (i.e. your.exe) when executed • Enjoy low memory footprint AND fast startup, while avoiding multiple parsings, even no source shipped • End-product got bigger. Who cares? (this is not FE)

Slide 24

Slide 24 text

December 2, 2016 V8 5.6 Released Ignition and TurboFan pipeline shipped

Slide 25

Slide 25 text

February 6, 2017 V8 5.7 Released

Slide 26

Slide 26 text

March 20, 2017 V8 5.8 Released

Slide 27

Slide 27 text

Apr. 19, 2017 V8 5.8 shipped in Chrome 58

Slide 28

Slide 28 text

A/B Test in progress

Slide 29

Slide 29 text

A/B Test in progress

Slide 30

Slide 30 text

How about Node.js? node date v8 6.10.2 2017-04-04 5.1.281.98 7.9.0 2017-04-11 5.5.372.43

Slide 31

Slide 31 text

No content

Slide 32

Slide 32 text

Future Node.js node date v8 8.0.0 2017-05-30 5.8 8.x.0 2017-06 5.9 8.y.0 2017-08 6.0