Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Moving Node.js and nodec to v8 Ignition

Moving Node.js and nodec to v8 Ignition

Minqi Pan

April 26, 2017
Tweet

More Decks by Minqi Pan

Other Decks in Programming

Transcript

  1. 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
  2. Chromium #593477 Result: (1) initial load, v8.CompileScript takes 165 ms

    (2) repeated loads, V8.ParseLazy takes 376 ms
  3. 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
  4. Motivation • Memory (major motivator) • Startup Speed • simpler

    script execution pipeline; reduce jank; make the interchange between V8’s various components more efficient; support ES2015+
  5. 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
  6. e.g. accumulator register • implicit register for many bytecodes to

    hold temporary results • avoiding the need to specify specific register operands, reduces the size of bytecodes • many JavaScript expressions involve chains of operations
  7. 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 file, though…
  8. 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)