Boosting WebAssembly Performance with Speculative Inlining and Deoptimization in V8

By • min read

Introduction

WebAssembly (Wasm) has long been prized for its near-native execution speed, especially when compiled from statically typed languages like C, C++, or Rust. However, the introduction of WasmGC—the garbage collection proposal—brings managed languages (Java, Kotlin, Dart) into the Wasm ecosystem, creating new optimization opportunities. In Chrome M137, V8 shipped two powerful speculative optimizations: speculative call_indirect inlining and deoptimization support. Together, they enable faster machine code by making assumptions based on runtime feedback. Early results show impressive gains: over 50% speedup on Dart microbenchmarks and 1–8% on larger real-world applications.

Background: Why WebAssembly Initially Skipped Speculative Optimizations

V8’s high-performance JavaScript execution relies heavily on speculative optimizations. Just-in-time (JIT) compilers gather feedback during execution and assume certain types (e.g., that a + b are both integers). If those assumptions later prove wrong, the engine performs a deoptimization (deopt)—discarding the optimized code and falling back to unoptimized code to collect more information. This trade-off yields dramatic speedups for dynamic languages.

In contrast, early WebAssembly (Wasm 1.0) did not need such speculation. Wasm binaries are statically typed: every function, instruction, and variable has a fixed type. Moreover, most Wasm code comes from ahead-of-time (AOT) compilers like Emscripten (LLVM) or Binaryen, which already apply extensive static analysis and optimization. As a result, Wasm 1.0 programs arrive already well-optimized, leaving little room for speculative improvements.

The Changing Landscape: WasmGC Demands Speculative Optimizations

WebAssembly has evolved. The WasmGC proposal introduces high-level features such as structs, arrays, subtyping, and garbage collection. This makes Wasm bytecode much closer to managed language runtime representations (e.g., the Dart VM or Java HotSpot). However, this richness also introduces dynamic behaviors that static analysis alone cannot fully predict. For example, a struct field access might involve complex class hierarchies, and function calls via call_indirect can target many different implementations.

Without speculation, the compiler must emit generic, type-check-heavy code for every operation. Speculative optimizations, on the other hand, let the JIT assume the most common case—and this is where V8’s new features shine.

Two Key Optimizations for Faster Wasm Execution

Speculative call_indirect Inlining

In Wasm, indirect function calls (call_indirect) are common in object-oriented languages—they resemble virtual method dispatch. Traditional Wasm compilers could not inline these calls because the target function is unknown until runtime. V8 now collects profiling information about which concrete function is most often called at each indirect call site. If the same target appears repeatedly, the JIT speculatively inlines it, generating streamlined machine code that skips the full dispatch.

But speculation carries risk: if a new target appears later, the inlined code becomes invalid. To handle this safely, V8 inserts a guard that checks the actual target against the expected one. If the guard fails, the engine triggers a deoptimization.

Deoptimization Support for WebAssembly

Until M137, V8 had no deoptimization mechanism for Wasm. If a speculation proved wrong, the only option was to abandon the entire optimized function. Now, V8 supports fine-grained deopts: the engine can roll back to a safe point (a “bailout” location) and resume execution with unoptimized, safe code. This is implemented by generating metadata that maps optimized code back to the original Wasm bytecode structure, allowing V8 to reconstruct the execution state.

Deoptimization is essential not only for recovering from speculative inlining failures but also as a foundation for future optimizations (e.g., speculating on array types or null checks).

Performance Results: Real-World Impact

The combination of speculative inlining and deoptimization delivers measurable speedups. On a set of Dart microbenchmarks compiled to WasmGC, V8 M137 achieves an average speedup of more than 50% compared to the previous version without these optimizations. In larger, realistic applications (such as those from the Dart framework and other WasmGC-based programs), the improvement ranges between 1% and 8%. While the gains are more modest in these scenarios, they demonstrate that speculative techniques can benefit even heavily optimized code paths.

These numbers are particularly encouraging because they come from a first implementation; further refinements in profiling heuristics and inlining thresholds are expected to widen the gap.

Future Directions

Deoptimization support is a key building block for even more aggressive speculative optimizations. Future work could include:

• Speculating on array element types (e.g., assuming an array of integers instead of a generic object array).
• Speculative null checks to eliminate guards.
• Adaptive inlining that adjusts based on runtime feedback over the lifetime of the application.
• Integration with profiling from WebAssembly’s own ref.test and br_on_cast instructions.

As WasmGC matures and more managed languages target WebAssembly, speculative optimization will become a cornerstone of high-performance execution on the web.

Conclusion

V8’s new speculative optimizations for WebAssembly—speculative call_indirect inlining and deoptimization—mark a significant step forward. By applying lessons from JavaScript JIT compilation to WasmGC, V8 now delivers faster execution for a new generation of WebAssembly programs. The early performance gains across microbenchmarks and real applications confirm the value of this approach. Developers compiling managed languages to WebAssembly can expect noticeable speed improvements in Chrome M137 and beyond.