Introduction
For over a decade, V8's top-tier optimizing compiler, Turbofan, was one of the few production compilers relying on the innovative Sea of Nodes (SoN) intermediate representation (IR). However, nearly three years ago, the V8 team began transitioning away from SoN toward a more traditional control-flow graph (CFG) IR named Turboshaft. Today, the entire JavaScript backend of Turbofan runs on Turboshaft, and WebAssembly compiles entirely through the new pipeline. Only two parts of Turbofan still use some SoN: the builtin pipeline (being gradually replaced) and the JavaScript frontend (being replaced by Maglev, another CFG IR). This article explores why V8 chose to abandon the Sea of Nodes.
The Legacy of Crankshaft
Twelve years ago, V8 had a single optimizing compiler, Crankshaft, built on a CFG-based IR. While initially delivering impressive performance gains, Crankshaft accumulated significant technical debt and several critical limitations:
- Excessive hand-written assembly code: Every new IR operator required manual assembly translation for all four supported architectures (x64, ia32, arm, arm64).
- Poor asm.js optimization: Crankshaft struggled to optimize asm.js, which was then considered vital for high-performance JavaScript.
- Inflexible control flow: Control flow was fixed at graph-building time; lowerings could not introduce new control flow. For instance, lowering
JSAdd(x, y)to branch on string types was impossible. - No try-catch support: Adding try-catch was extremely challenging—multiple engineers spent months without success.
- Severe performance cliffs and bailouts: Using certain features could cause 100× slowdowns, making performance unpredictable for developers.
- Deoptimization loops: Crankshaft often re-optimized functions with the same speculative assumptions that had just caused deoptimization, leading to repeated cycles.
These flaws motivated the creation of Turbofan with a radically different IR—the Sea of Nodes.
The Sea of Nodes Approach
Turbofan adopted the Sea of Nodes IR, where operations and data dependencies are nodes in a graph, and control flow is only implicitly defined through side effects. This design elegantly solved Crankshaft's limitations: it allowed arbitrary lowerings (even those introducing new control flow), supported try-catch natively, and eliminated many performance cliffs by enabling fine-grained optimizations like global value numbering and code motion. However, the sea of nodes also introduced new challenges over time.
Why We Moved to Turboshaft
Despite SoN's theoretical advantages, several practical concerns drove the shift to Turboshaft, a more conventional CFG IR:
- Compilation complexity: SoN's graph-based nature made passes and transformations difficult to debug, maintain, and reason about. The freedom of node reordering often led to subtle bugs hard to reproduce.
- Memory and compile-time overhead: The SoN graph required more memory and CPU time to build and traverse compared to a linear CFG, hurting compilation speed—especially critical in just-in-time (JIT) compilation.
- Limited optimization insight: While SoN enables global optimizations, many real-world benefits could be achieved with simpler CFG passes, and the complexity of SoN made it harder to implement new optimizations.
- Deployment challenges: The experimental nature of SoN made it harder to test and ship. Turboshaft, by being more structured, allowed incremental replacement without breaking existing functionality.
- Alignment with WebAssembly: WebAssembly's linear control flow and structured blocks naturally fit a CFG IR, making Turboshaft a better fit for Wasm compilation.
Over the past three years, the V8 team methodically replaced SoN components with Turboshaft, measuring performance and stability at each step. The transition improved compile times, reduced memory usage, and simplified the codebase—without sacrificing generated code quality.
The Future
Today, the JavaScript backend of Turbofan fully uses Turboshaft, and WebAssembly is entirely compiled through it. The last remnants of SoN—the builtin pipeline and the JavaScript frontend—are being phased out: builtins will move to Turboshaft, and the frontend is being replaced by Maglev, another CFG-based compiler. This migration marks V8's return to a more traditional, maintainable IR while preserving the optimization power needed for modern JavaScript and WebAssembly.
The journey from Crankshaft to SoN to Turboshaft reflects the evolving trade-offs in compiler design: theoretical elegance must balance with practical engineering. V8's experience shows that while novel IRs can solve immediate problems, long-term success often requires simplicity and maintainability.