Moving Node.js and nodec to v8 Ignition

Transcript

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

   View Slide

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
   

   View Slide

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

   View Slide

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
   

   View Slide

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

   View Slide

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+
   

   View Slide

7. Old Architecture
   

   View Slide

8. Multiple Parsing
   Machine Code
   

   View Slide

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

   View Slide

10. New Architecture
    

    View Slide

11. Memory Problem
    JIT-ed code
    

    View Slide

12. Memory Optimized
    

    View Slide

13. Mobile Top 10 Benchmark
    

    View Slide

14. View Slide

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

    View Slide

16. Startup Speed Problem
    actual executing
    

    View Slide

17. Startup Speed Optimized
    

    View Slide

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
    

    View Slide

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
    

    View Slide

20. Comparing with the others
    

    View Slide

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…
    

    View Slide

22. 去吧！Node.js Compiler
    

    View Slide

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)
    

    View Slide

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

    View Slide

25. February 6, 2017
    V8 5.7 Released
    

    View Slide

26. March 20, 2017
    V8 5.8 Released
    

    View Slide

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

    View Slide

28. A/B Test in progress
    

    View Slide

29. A/B Test in progress
    

    View Slide

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
    

    View Slide

31. View Slide

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
    

    View Slide