.NET 8에서 WASM 코드로 변환하는 JIT 예고

dimohy · 11월 4, 2022, 12:06오후

지금의 .NET 웹어셈블리 구현은 인터프리터 방식이거나 AOT 입니다. 아직은 WASM 코드로 변환하는 JIT은 없으며 .NET 8에서 제공됩니다.

github.com/dotnet/runtime

Introduce WASM JITs for interpreter opcodes, do_jit_call, and interp_entry wrappers

dotnet:main ← kg:wasm-jiterpreter

opened 02:04AM - 01 Oct 22 UTC

kg

+8808 -23

This PR introduces a "jiterpreter" just-in-time WASM compiler for interpreter op…codes along with a set of specialized WASM JIT compilers to improve the performance of `interp_entry` and `do_jit_call`. The result is significantly improved performance for pure-interpreter workloads along with measurable speedups for interp->aot and aot->interp transitions in mixed mode AOT applications. The jiterpreter can be thought of as an additional layer on top of interpreter tiering, and works by inserting "trace entry points" into interpreter opcode streams. Once an entry point is reached often enough, the JIT kicks in to compile as many following interpreter opcodes into WASM as possible. Once a jitted 'trace' is available, when the interpreter reaches the entry point it can invoke the trace to natively execute dozens of interpreter opcodes at once without loop dispatch overhead. Any trace entry point that fails to JIT is replaced with a special NOP. See https://paper.dropbox.com/doc/Jiterpreter-For-WebAssembly--BqLn88GjC3z4GDuE09vamtw4Ag-mJ5TRc7xF1PNAGMgwU49K for a more detailed overview of the jiterpreter design. Due to browser limitations it is not possible to JIT entire methods at once, so entry points have to be placed at key locations within a given method, like immediately after a backwards branch target (for loop bodies). The jiterpreter has a simple single-pass compiler, so when it encounters an opcode or complex pattern it can't handle it 'bails out' to return control to the interpreter. Complex control flow like exceptions, calls and returns are also handled by bailing out to the interpreter. Traces share the interpreter's state and locals instead of maintaining their own, which allows seamless bailouts and maintains existing GC/thread safety characteristics. The jiterpreter infrastructure is also used to on-demand compile specialized wrappers for `interp_entry` and `do_jit_call`. All the critical reflective/dynamic work (like enumerating parameter types) is done at compile time to produce a small, branchless dispatcher that is able to set up an interpreter stack frame or invoke native code with fewer copies than the generic wrappers currently used. To determine which `do_jit_call` sites should be optimized, we maintain a hit counter much like we do for traces, and only JIT the most frequently executed ones. For `interp_entry` we optimize all of them. An additional optimization in this PR leverages the jiterpreter infrastructure to optimize all `do_jit_call` execution by generating a dedicated function (either in WASM or JS) to trap exceptions and dispatch native calls. The current implementation uses `mono_llvm_cpp_catch_exception` to perform an indirect call bounced through JavaScript, which adds a measurable amount. By using specialized code we can perform a direct call using WASM Exception Handling (if available) or using a specialized JavaScript function that doesn't do any indirection or table lookups. This optimization by itself speeds up System.Runtime.Tests in AOT mode by about 2 seconds. You can find the function template in the new `do-jit-call.wat` and `do-jit-call.wasm` files. The jiterpreter's features are configurable using a set of new runtime options, the key ones being: * `--jiterpreter-enable-traces` Enables the insertion of trace entry points in interpreter functions and JIT compilation for those entry points. * `--jiterpreter-enable-interp-entry` Enables the generation of specialized interp_entry wrappers. Note that this option is not retroactive, and these are typically all generated at app startup. * `--jiterpreter-enable-jit-call` Enables the generation of specialized do_jit_call wrappers. * `--jiterpreter-enable-stats` Enables dumping detailed statistics on the jiterpreter, including how many WASM functions were jitted, which interpreter opcodes caused the most failures, and how much time was spent. If statistics are enabled they are automatically dumped at app exit, but they can be manually dumped using an INTERNAL api. This PR also contains some scaffolding changes and interpreter optimizations that were necessary in order to finish it and test it on benchmark scenarios: * Added interpreter opcodes for Math.Min/Max/Abs (without these lots of compute is impossible to JIT) * Updated a couple of the sample csprojs to make it easy to turn AOT+trimming on or off at build time * Lowered browser-bench's default heap size (the default can cause OOM during runs, partly due to a memory leak in Chrome) * Adds a simple raytracer sample that is engineered to transition in and out of the interpreter frequently when AOT'd, to serve as a useful benchmark for various parts of the PR * Updated the 'cwraps' typescript API to produce useful error messages when an exported C function is missing * Replaced mono_wasm_array_length C API with a new safe mono_wasm_array_length_ref variant * Added an optimization to remove the linker placeholders that currently sit between the runtime's C and TypeScript glue (see startup.ts)

dimohy · 11월 4, 2022, 10:13오후

다양한 이유로 인해 완전한 JIT은 아니고 기존 모노 인터프리터 기반으로 부분 JIT을 수행하는 Jiterpreter 입니다.