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

8002c84eb4c18170632f8fb7efb09288?s=128

Minqi Pan

April 26, 2017
Tweet

Transcript

  1. Moving Node.js and nodec to Ignition Minqi Pan

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

    (2) repeated loads, V8.ParseLazy takes 376 ms
  4. 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
  5. Facebook uses a transpiler to combine individual modules into a

    single file. E.g. Chromium #593477
  6. Motivation • Memory (major motivator) • Startup Speed • simpler

    script execution pipeline; reduce jank; make the interchange between V8’s various components more efficient; support ES2015+
  7. Old Architecture

  8. Multiple Parsing Machine Code

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

  10. New Architecture

  11. Memory Problem JIT-ed code

  12. Memory Optimized

  13. Mobile Top 10 Benchmark

  14. None
  15. run-once or non-hot code now stored more compactly in bytecode

    form
  16. Startup Speed Problem actual executing

  17. Startup Speed Optimized

  18. 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
  19. 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
  20. Comparing with the others

  21. 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…
  22. 去吧!Node.js Compiler

  23. 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)
  24. December 2, 2016 V8 5.6 Released Ignition and TurboFan pipeline

    shipped
  25. February 6, 2017 V8 5.7 Released

  26. March 20, 2017 V8 5.8 Released

  27. Apr. 19, 2017 V8 5.8 shipped in Chrome 58

  28. A/B Test in progress

  29. A/B Test in progress

  30. 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
  31. None
  32. 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