Running JS via WASM faster with JIT
So, we are adding a backend for the SpiderMonkey’s codegen to enable JIT support for JavaScript running through Wasm. Sounds a bit cryptic so let’s divide it into parts. SpiderMonkey is a JavaScript engine which is used for running JavaScript inside the Firefox browser. SpiderMonkey is written in C++ and supports compilation into the Wasm module, see live demo - https://mozilla-spidermonkey.github.io/sm-wasi-demo/. However, SpiderMonkey compiled into the Wasm module supports execution of JavaScript only in the interpreter-only mode and it doesn’t support just-in-time compilation because there is no Wasm backend for that. There are backends for Arm, X86, X64 etc but there is none for Wasm. Why do we want to add support for JIT? Well, because we want speed. Right now there is no solution to run JS scripts via Wasm fast, there are only interpreters. Why does JIT improve performance? The reasons are the same for why an interpreter is slower than a compiler - because it eliminates the interpreter loop, uses a more efficient ABI and, more importantly, it can specialize polymorphic operations in JavaScript. So, we not only enable the JIT tier in SpiderMonkey for Wasm but we also provide support for inline caches. Inline caches is a mechanism for specializing the behavior of particular operations like plus or a call to specific arguments provided at runtime. With all that we can generate Wasm modules on the fly, instantiate them, and link them to provide from ~2x to ~11x speedup over the interpreter. In the talks we will cover how the whole scheme works with SpiderMonkey: 1. How to link modules on the fly into SpiderMonkey.wasm 2. How to add an exotic Wasm backend into SpiderMonkey’s supported backend line - X64, X86, Arm, Wasm 3. How to use the whole solution in the cloud instead of QuickJS 4. How to get a speedup of your JS over wasm with test data. Wasm I/O 2024 14 - 15 Mar, 2024 Barcelona https://2024.wasmio.tech/
Recommandé
Recommandé
Contenu connexe
Similaire à Running JS via WASM faster with JIT
Similaire à Running JS via WASM faster with JIT (20)
Plus de Igalia
Plus de Igalia (20)
Dernier
Dernier (20)
Running JS via WASM faster with JIT
- 1. Running JS via Wasm Faster with JIT Dmitry Bezhetskov Wasm I/O 2024
- 2. JS is getting popular
- 3. The State of WebAssembly 2021 - 2023
- 4. How to run JS inside Wasm? ● Mozilla SpiderMonkey ● QuickJS
- 5. SpiderMonkey - Size 5Mb - Support only interpreter mode + Good support of JS standard and actively developed credit: @b_atchison98
- 6. QuickJS + Size 800Kb - Support only interpreter mode - Less support of JS standard + Fast interpreter and preprocessing support credit: @sanghoon71
- 7. JavaScript Interpreter ● Slow math ● Overhead on dispatch ● No specialization ● No optimizations
- 8. Wishful thinking + Better than interpreter throughput + Industrial support of new features of JS + Reasonable size + Preprocessing and/or AOT support
- 9. JIT support for JS with Wasm
- 10. The plan
- 14. SpiderMonkey + Wasm backend + Industrial support of JS + Interpreter for cold code + JIT for hot code - Size 5mb + … more in the last section
- 15. How can we add Wasm as a backend?
- 16. SpiderMonkey interface for backend Bytecode
- 17. SpiderMonkey interface for backend Bytecode C++ Interpreter
- 18. SpiderMonkey interface for backend Bytecode C++ Interpreter BaselineInterpreter BaselineJIT Ion Warp
- 19. SpiderMonkey interface for backend Bytecode C++ Interpreter BaselineInterpreter BaselineJIT Ion Warp Masm
- 20. Masm Wasm
- 22. Registers Masm Locals & Globals Wasm Direct stack access Own restricted stack
- 23. Registers Masm Locals & Globals Wasm Direct stack access Own restricted stack Add32, Mul32, … Add32, Mul32, …
- 24. Registers Masm Locals & Globals Wasm Direct stack access Own restricted stack Add32, Mul32, … Add32, Mul32, … Jumps addr & Labels Structured control flow & blocks
- 25. Control flow
- 26. Control flow
- 27. Control flow … load script into scratch compare scratch against 0 fail push 0
- 28. … load script into scratch compare scratch against 0 fail push 0
- 29. … load script into scratch compare scratch against 0 fail push 0
- 30. Control flow resume 1. Control flow obtained from Masm is structured 2. Using classic compilers algorithms for layouting CFG with loops
- 33. Registers masm.push(rcx); masm.push(rax); masm.push(rdx); … MASM (func (param $rcx i64) (param $rax i64) (param $rdx i64) local.get 0 local.get 1 local.get 2 … ) WAT function foo() {...} JS
- 34. Stack Local “foo” Saved FP Return Address Arg0 Native stack
- 35. Stack Local “foo” Saved FP Return Address Arg0 Native stack local 0 I32.const offset I32.const 4 … Wasm Stack
- 36. Stack __stack_pointer Local “foo” Saved FP Return Address Arg0 Native stack local 0 I32.const offset I32.const 4 … Wasm Stack
- 37. Resume of compilation 1. Recreate CFG from Masm 2. Use the structured property of SpiderMonkey to layout blocks 3. Represent registers as parameters 4. Import __stack_pointer to maintain the same stack structure
- 39. Code installation How to use freshly compiled wasm code?
- 40. Code installation How to use freshly compiled wasm code? Solution: ● wasmtime is able to compile and instantiate new modules at runtime ● we will patch SpiderMonkey memory to “install” code
- 43. WebAssembly.Memory SpiderMonkey.wasm WebAssembly.Table source.js Do we have compiled code for source.js?
- 44. WebAssembly.Memory SpiderMonkey.wasm WebAssembly.Table source.js Do we have compiled code for source.js? Execute in Interpreter N o
- 45. WebAssembly.Memory SpiderMonkey.wasm WebAssembly.Table source.js Do we have compiled code for source.js? Y e s load index $idx call_indirect $idx Execute in Interpreter N o
- 46. WebAssembly.Memory SpiderMonkey.wasm WebAssembly.Table source.js Do we have compiled code for source.js? Y e s load index $idx call_indirect $idx Execute in Interpreter N o jitcode.wasm
- 47. WebAssembly.Memory SpiderMonkey.wasm WebAssembly.Table source.js Do we have compiled code for source.js? Y e s load index $idx call_indirect $idx Execute in Interpreter N o jitcode.wasm
- 48. WebAssembly.Memory SpiderMonkey.wasm WebAssembly.Table source.js Do we have compiled code for source.js? Y e s load index $idx call_indirect $idx Execute in Interpreter N o jitcode.wasm f1
- 49. WebAssembly.Memory SpiderMonkey.wasm WebAssembly.Table source.js Do we have compiled code for source.js? Y e s load index $idx call_indirect $idx Execute in Interpreter N o jitcode.wasm f1
- 50. SpiderMonkey.wasm WebAssembly.Table source.js Do we have compiled code for source.js? Y e s load index $idx call_indirect $idx Execute in Interpreter N o jitcode.wasm f1 WebAssembly.Memory
- 51. When to call the compilation?
- 57. wasmtime driver SpiderMonkey execute source.js return result ... compile source.js postpone compilation
- 58. wasmtime driver SpiderMonkey execute source.js return result ... compile source.js postpone compilation run all pending compilations
- 59. wasmtime driver SpiderMonkey execute source.js return result ... compile source.js postpone compilation run all pending compilations instantiate bytes
- 60. wasmtime driver SpiderMonkey execute source.js return result ... compile source.js postpone compilation run all pending compilations execute source.js instantiate bytes
- 61. wasmtime driver SpiderMonkey execute source.js return result ... compile source.js postpone compilation run all pending compilations execute source.js execute jit version instantiate bytes
- 62. Results
- 65. Why we are fast? ● CacheIR support from SpiderMonkey ● Inlining for known targets
- 66. Readiness ● Don’t support whole JS, but we pass 83% (9867 out of 11340) of jit-tests ● Working on upstream, see bug 1863986 at bugzilla
- 67. How to use all of this?
- 68. Three modes of execution 1. Full specialization 2. Sharing scheme 3. Call compilation each time
- 71. Full specialization source.js test data
- 72. Full specialization source.js test data specialized
- 73. Full specialization + No runtime codegen if needed + Full power of JIT with Baseline and ICs + Full isolation - Big size ~5Mb
- 74. Sharing scheme
- 76. Sharing scheme source.js test data
- 77. Sharing scheme source.js test data jit_module
- 78. wasmtime driver
- 83. wasmtime driver execute source.js instantiate shared SM install jit_module.wasm execute source.js with JIT
- 84. Sharing scheme ● SpiderMonkey code is shared ● One instance per client ● jit_module is used to install previously compiled code
- 85. Call compilation each time ● Emulation native SpiderMonkey ● Slow, because we don’t batch compilation calls and run compilation at runtime ● Used for tests
- 86. Resume ● Implemented new Wasm backend for SpiderMonkey ● Supported ICs and provided promising perf results - from 2x to 11x ● Passed most of the 83% of jit-tests ● Provided interesting modes of execution for embedding or cloud ● Unblocked higher JIT tiers like Warp or Ion
- 87. Thanks ● Thanks to all people from Shopify involved for sponsoring this work ○ Special thanks to Mike Shaver and Saúl Cabrera who patiently provides us feedback for our work ● Thanks to SpiderMonkey team for reviewing our patches
- 88. Happy to hear your opinion