Enhancing WebAssembly Performance with Speculative Inlining and Deoptimization in V8

Introduction

Modern web applications demand ever-faster execution of compiled code. WebAssembly (Wasm) has long been praised for its near-native speed, but new features like WasmGC introduce challenges that require innovative compiler techniques. In Chrome M137, V8 shipped two powerful optimizations: speculative call_indirect inlining and deoptimization support for WebAssembly. Together, they enable the engine to generate more efficient machine code by acting on runtime feedback, significantly boosting performance—especially for garbage-collected languages compiled to Wasm. This article explains how these optimizations work, why they matter, and what performance gains they deliver.

Background: Speculative Optimization in JavaScript vs. WebAssembly

For years, JavaScript engines like V8 have relied heavily on speculative optimization. A just-in-time (JIT) compiler observes how code behaves during execution and makes assumptions—for example, that a variable is always an integer. It then produces fast, specialized machine code. If later execution violates those assumptions, the engine performs a deoptimization (or “deopt”): it discards the optimized code and falls back to a slower, generic version while continuing to collect feedback for future recompilation.

In contrast, traditional WebAssembly (Wasm 1.0) did not need such speculation. Wasm’s static typing of functions, instructions, and variables provides a wealth of information at compile time. Moreover, most Wasm binaries come from C, C++, or Rust—languages already amenable to static analysis. Toolchains like Emscripten (based on LLVM) and Binaryen perform aggressive ahead-of-time optimizations, producing well-optimized binaries that run fast without runtime speculation.

Motivation: The Rise of WasmGC

WebAssembly’s capabilities expanded with the WasmGC proposal, which adds garbage collection support. This enables “managed” languages such as Java, Kotlin, and Dart to compile to Wasm efficiently. WasmGC introduces high-level constructs like structs, arrays, subtyping, and operations on those types. These features are far more abstract than Wasm 1.0’s low-level instruction set, and static optimization alone cannot always produce optimal code. To unlock the full performance potential of WasmGC programs, V8 now applies the same kind of speculative optimization that has proven so effective for JavaScript.

The Two Optimizations in Detail

Speculative call_indirect Inlining

Indirect function calls (via call_indirect in WebAssembly) are inherently slower than direct calls because the target must be looked up at runtime. WasmGC encourages object-oriented patterns with polymorphic dispatch, making indirect calls common. To speed them up, V8 now speculatively inlines the most frequent target functions. By collecting runtime feedback, the engine identifies which function is likely called at a particular call site and replaces the indirect call with a direct, inlined copy of that function’s code. This eliminates call overhead and enables further optimizations like constant propagation within the inlined body. If the speculation proves wrong (a different function is called), a deoptimization triggers, and execution continues correctly using the generic path.

Deoptimization Support for WebAssembly

Deoptimization is the safety net that makes speculative optimization viable. V8’s existing deoptimization machinery—originally designed for JavaScript—has been extended to WebAssembly. When a speculative assumption fails (e.g., an inlined call target is wrong, or a type assumption is broken), V8 must seamlessly revert to unoptimized WebAssembly code. This involves reconstructing the execution state of the WebAssembly virtual machine from the optimized machine code, ensuring that values, locals, and operand stack mirrors are correctly restored. Once deoptimized, the engine continues execution using the baseline compiler and collects fresh feedback, allowing it to re-speculate and tier up again later.

Performance Benefits

The combination of speculative inlining and deoptimization yields impressive speedups, particularly for WasmGC programs. In Dart microbenchmarks representative of dynamic language patterns, the average improvement exceeds 50%. On larger, real-world applications and benchmarks (e.g., those from the Dart Web platform or other managed-language frameworks), the speedup ranges from 1% to 8%. While modest in absolute terms, these gains are valuable because they come with no downside—deoptimizations ensure correctness, and the optimizations only apply where feedback indicates they are safe.

Future Directions

Deoptimization is not only a tool for supporting inlining; it is a foundation for many other speculative optimizations. In the future, V8 could use runtime feedback to optimize type checks, monomorphize polymorphic operations, or even guide structure layout in WasmGC objects. As WasmGC matures and more languages target it, these speculative techniques will become increasingly important to close the performance gap with native compilation.

Conclusion

With the introduction of speculative call_indirect inlining and deoptimization in Chrome M137, V8 brings the proven tools of JavaScript JIT compilation to WebAssembly. While Wasm 1.0 benefited from static typing and ahead-of-time optimization, WasmGC’s richer type system demands runtime feedback. These new optimizations boost performance substantially—especially for managed languages—and lay the groundwork for even more advanced speculative techniques in the future. WebAssembly continues to evolve, and with it, the engines that execute it must adapt to keep the web fast and efficient.