10 Things You Need to Know About WebAssembly's New Speculative Optimizations in V8

WebAssembly has long been praised for its predictable performance, but with the arrival of Google Chrome M137, V8 introduces a paradigm shift: speculative optimizations powered by runtime feedback. This update brings two key techniques—speculative call_indirect inlining and deoptimization (deopt) support—that push WebAssembly execution speeds to new heights, especially for WasmGC programs. In this listicle, we unpack ten essential facts about these optimizations, from their background to their real-world impact.

1. What Are Speculative Optimizations?

Speculative optimizations allow a JIT compiler to generate fast machine code by making assumptions based on past program behavior. For example, if a variable has always been an integer, the compiler can emit specialized integer arithmetic instead of generic code that handles all types. If an assumption later fails, the system must gracefully recover—typically via deoptimization. This approach has been central to JavaScript performance in V8 for years, and now it's coming to WebAssembly.

10 Things You Need to Know About WebAssembly's New Speculative Optimizations in V8 — Source: v8.dev

2. WebAssembly's Historical Performance Advantage

Unlike JavaScript, WebAssembly (Wasm 1.0) already benefited from static typing and ahead-of-time compilation via toolchains like Emscripten (LLVM) or Binaryen. Functions, instructions, and variables are all statically typed, eliminating the guesswork. This made speculative optimizations unnecessary for the original WebAssembly specification, as compilers could produce highly optimized binaries without needing runtime feedback.

3. Enter WasmGC: The Catalyst for Change

The WebAssembly Garbage Collection (WasmGC) proposal extends WebAssembly to support managed languages like Java, Kotlin, and Dart. WasmGC introduces high-level bytecode with rich types—structs, arrays, subtyping—and operations on them. This abstraction level means that the generated machine code can be further improved by speculative optimizations, motivating V8 to adopt techniques previously reserved for JavaScript.

4. The Dynamic Duo: Inlining and Deopts

The two core optimizations shipped in Chrome M137 are speculative call_indirect inlining and deoptimization support. Together, they form a feedback loop: the compiler collects runtime data to identify hot indirect calls, inlines them speculatively, and if the assumptions break, a deoptimization safely falls back to unoptimized code. This combination yields better machine code than static analysis alone.

5. What Is Speculative call_indirect Inlining?

call_indirect is a WebAssembly instruction for dynamic function calls (like function pointers). Traditionally, the compiler emitted a generic invocation sequence. With speculative inlining, V8 tracks which function is most often called at a given call site and directly inlines that function's code. If a different function shows up later, the compiled code is invalidated, and execution reverts to the generic path via a deoptimization.

6. Deoptimization: The Safety Net

Deoptimization (deopt) is the mechanism that rolls back execution to a safe, unoptimized state when a speculative assumption fails. V8 already uses deopts extensively for JavaScript. For WebAssembly, implementing deopt required careful handling of low-level control flow and memory. Now, if an inlined function target changes, the optimizer can discard the specialized code and continue executing in a less optimized but correct way.

7. Microbenchmark Results: Huge Gains for Dart

On a set of Dart microbenchmarks, the combination of speculative inlining and deoptimization yields an average speedup of over 50%. Dart, when compiled to WasmGC, heavily uses indirect calls and object-oriented patterns, making it an ideal candidate. These microbenchmarks stress tight loops and polymorphic call sites, where speculative optimizations shine.

8. Real-World Application Performance: Modest but Meaningful

Larger, more realistic applications and benchmarks show speedups between 1% and 8%. While smaller than the microbenchmark gains, these improvements are significant because they come without code changes—Chrome users automatically benefit. Applications like compilers, game engines, and data processing tools see tangible reductions in execution time, especially when using WasmGC.

9. A Foundation for Future Optimizations

Deoptimization support is not just for this single optimization—it's an architectural building block. Future V8 releases can leverage deopts to implement other speculative techniques, such as guarded type specialization or dynamic constant propagation. As WasmGC evolves, the feedback-driven approach will enable progressively smarter machine code generation.

10. What's Next for WebAssembly Optimization?

With these optimizations now live in Chrome M137, the door is open for more advanced schemes. V8 engineers are exploring additional runtime feedback mechanisms, smaller deopt overheads, and deeper integration with WasmGC’s type system. The long-term vision is a WebAssembly runtime that rivals native compilers in both speed and adaptability, all while maintaining the safety and portability of the platform.

Conclusion: The introduction of speculative optimizations marks a turning point for WebAssembly, bridging the gap with JavaScript's adaptive performance. By bringing deopts and inlining to Wasm and WasmGC, V8 has unlocked significant speedups—especially for managed languages—and laid the groundwork for even smarter optimizations ahead. Whether you're a Dart developer seeing 50% faster microbenchmarks or a C++ user gaining a few percent on real apps, these changes make WebAssembly more powerful than ever.

Tags: