Accelerating WebAssembly: Q&A on Speculative Inlining and Deoptimization in V8
WebAssembly (Wasm) has long relied on static analysis for performance, but recent advancements in V8—the JavaScript engine powering Chrome—introduce speculative optimizations that were once reserved for JavaScript. By combining speculative call_indirect inlining with deoptimization support, V8 can now generate faster machine code based on runtime feedback. This is especially beneficial for WasmGC programs compiled from managed languages like Dart, Java, or Kotlin. In this Q&A, we explore how these optimizations work, why they matter, and the performance gains observed in Chrome M137.
1. What are speculative optimizations and why were they not needed for WebAssembly until recently?
Speculative optimizations are techniques where a compiler makes assumptions about program behavior based on runtime feedback to generate more efficient machine code. For example, if a variable a + b has always been an integer addition, the compiler can produce specialized code for that case, avoiding generic, slower paths. In JavaScript, V8 relies heavily on such speculation and uses deoptimization—falling back to unoptimized code—if assumptions are violated.
Traditionally, WebAssembly did not require these optimizations because WebAssembly 1.0 is statically typed. Functions, instructions, and variables are clearly defined, and compilers like Emscripten or Binaryen can optimize ahead-of-time. However, the introduction of WasmGC (Garbage Collection proposal) changed this. WasmGC brings high-level features like structs, arrays, and subtyping, which are harder to optimize statically. Now, speculative optimizations become valuable for WasmGC programs, just as they are for JavaScript.
2. How do deoptimizations work in V8 and why are they important for WebAssembly now?
Deoptimization is the mechanism by which V8 rolls back optimized code when the assumptions it was based on are no longer valid. For instance, if a function was inlined assuming a certain type, but the actual type is different, V8 throws away the optimized code and resumes execution in a slower, but correct, unoptimized version. This ensures correctness without sacrificing performance in common cases.
For WebAssembly, deoptimizations were unnecessary because Wasm 1.0 programs rarely change their behavior at runtime. But WasmGC code can have polymorphic operations—like method dispatch on objects—where the exact type may vary. Without the ability to deoptimize, V8 would have to generate generic code that handles all possible types, which is slower. By pairing speculative inlining with deoptimization, V8 can generate highly optimized code that assumes the most common type, and safely fall back if that assumption fails. This combination is a building block for future optimizations.
3. What is speculative call_indirect inlining and how does it improve performance?
In WebAssembly, call_indirect is an instruction that calls a function through a table of function pointers. This is similar to virtual method calls in object-oriented languages. Without optimization, each call_indirect requires a table lookup, type check, and indirect jump—operations that are relatively expensive and hinder inlining.
Speculative call_indirect inlining lets V8 assume that a particular call_indirect always targets the same function, based on runtime feedback. Instead of the generic lookup, the compiler can directly call that function and even inline its body, eliminating call overhead. If later the call targets a different function, the assumption is broken and V8 deoptimizes to the generic path. This optimization is especially effective for WasmGC programs, where polymorphic calls are common. Performance measurements show significant improvements, especially in Dart microbenchmarks, where the combination of inlining and deoptimization yields speedups of over 50% on average.
4. What speedups have been observed from these optimizations?
On a set of Dart microbenchmarks for WebAssembly (WasmGC), the combination of speculative call_indirect inlining and deoptimization support achieved an average speedup of more than 50%. For larger, realistic applications and benchmarks, the speedup ranged between 1% and 8%. These numbers are from the V8 team’s testing with Chrome M137.
While the gains are modest on larger programs, the impact on smaller, hotspot-heavy code is dramatic. This is typical for speculative optimizations—they accelerate frequently executed paths. Moreover, these optimizations lay the groundwork for future improvements. By having deoptimization support in WebAssembly, V8 can now apply other speculative techniques (like type specialization or inline caching) that were previously impossible. Over time, as more WasmGC applications emerge, the cumulative benefit will grow, making WebAssembly a more competitive target for managed languages.
5. How does WasmGC change the optimization landscape for WebAssembly?
WasmGC introduces high-level type features such as structs, arrays, and subtyping, as well as operations like field access and method calls. These are similar to constructs found in object-oriented languages. Unlike WebAssembly 1.0, where memory is opaque and types are primitive (i32, f64, etc.), WasmGC programs have richer runtime type information. This makes static, ahead-of-time optimization more challenging because the actual types may only be known at runtime.
Consequently, speculative optimizations that work well for JavaScript become applicable to WasmGC. For instance, a method call on an object might always resolve to the same implementation in the hot path. By speculatively inlining that method, V8 eliminates dynamic dispatch overhead. Deoptimization ensures correctness when a different implementation is needed. Without WasmGC, such speculation would be unnecessary or impossible. Thus, WasmGC shifts WebAssembly towards a model where just-in-time optimization and feedback-driven compilation are essential for peak performance.
6. What does the future hold for speculative optimizations in WebAssembly?
The current implementation of speculative call_indirect inlining and deoptimization is just one example of what becomes possible. The V8 team plans to extend these mechanisms to other areas: for example, speculatively specializing on the shapes of WasmGC objects, or inlining based on function hotness. Deoptimization also enables on-stack replacement, which allows transitioning between optimized and unoptimized code even while a function is executing.
Moreover, these optimizations are not limited to WasmGC—they could also benefit traditional WebAssembly if future proposals introduce more dynamic features. As more languages (Java, Kotlin, Dart) target WasmGC, the demand for efficient execution will grow. Speculative techniques will be key to closing the performance gap with native code. Developers compiling to WebAssembly can expect continuous improvements in V8, making their applications faster without any code changes.