Navigating Away: V8’s Transition from Sea of Nodes to Turboshaft

Introduction

For over a decade, V8’s top-tier optimizing compiler, Turbofan, stood out as one of the few large-scale production compilers built on a Sea of Nodes (SoN) intermediate representation. However, since 2021, the V8 team has been systematically replacing SoN with a more traditional Control-Flow Graph (CFG) IR called Turboshaft. Today, the entire JavaScript backend of Turbofan has migrated to Turboshaft, and WebAssembly uses it throughout its pipeline. Only two areas still retain some SoN: the builtin pipeline (being slowly replaced) and the JavaScript pipeline’s frontend (being replaced by Maglev, another CFG-based IR). This article explains the reasons behind this architectural shift and what it means for V8’s future.

The Legacy of Crankshaft

To understand the move, we must first look at V8’s earlier optimizing compiler, Crankshaft. Launched in 2013, Crankshaft used a CFG-based IR and delivered significant performance gains despite its early limitations. Over time, however, technical debt accumulated, leading to several critical issues:

• Excessive hand-written assembly: Each new IR operator required manual assembly code for all four supported architectures (x64, ia32, arm, arm64), slowing development.
• Poor asm.js optimization: Crankshaft struggled with asm.js, which was then seen as a key path to high-performance JavaScript.
• No control flow in lowerings: Control flow was fixed at graph building time. This prevented common compiler patterns, such as lowering a high-level JSAdd(x, y) into a conditional that checks operand types before calling StringAdd.
• Try-catch unsupported: Despite months of effort, supporting try-catch constructs proved impossible within Crankshaft’s architecture.
• Performance cliffs and bailouts: Using specific features or encountering certain edge cases could cause performance to drop by a factor of 100, making it hard for developers to write predictable, efficient code.
• Deoptimization loops: Crankshaft would often reoptimize a function with the same speculative assumptions that had just caused a deoptimization, leading to runaway cycles.

These pain points motivated the creation of Turbofan, which aimed to be more flexible and ambitious.

Why Sea of Nodes Was Chosen

When designing Turbofan, the team wanted to overcome Crankshaft’s rigidity. The Sea of Nodes representation offered unique advantages: it decoupled scheduling from optimization, allowing the compiler to reorder operations freely and apply complex global optimizations. SoN treated every value and control dependency as a node in a graph, with no predetermined order. This flexibility was ideal for aggressive optimizations like global value numbering, loop-invariant code motion, and advanced inlining.

Moreover, SoN naturally supported lazy deoptimization and speculative optimizations, which were central to V8’s ability to generate fast JavaScript code. The graph could represent both optimistic and fallback paths, and the compiler could seamlessly revert to less optimized code when assumptions failed. For several years, Turbofan thrived using SoN, delivering major performance improvements over Crankshaft.

The Challenges with Sea of Nodes

Despite its power, SoN introduced significant complexity. The graph was inherently more difficult to debug, visualize, and modify compared to a linear CFG. Common tasks like inserting new control flow or performing basic lowerings required deep understanding of the graph’s structure. The compilation speed also suffered because SoN’s scheduling phase (converting the graph into a linear sequence) was computationally expensive.

Furthermore, as V8 evolved, many of the optimizations that SoN enabled became less critical. Modern JavaScript engines rely heavily on fast compilation times and just-in-time (JIT) performance, not just peak runtime performance. The overhead of SoN’s scheduling and graph manipulation hurt Turbofan’s ability to compile quickly, especially for short-lived functions. The team also found that many optimizations once thought to require SoN could be implemented effectively with a CFG IR, thanks to better analysis passes and incremental compilation techniques.

The Shift to Turboshaft

Recognizing these drawbacks, the V8 team began developing Turboshaft, a new CFG-based IR that retained the best practices of Turbofan while simplifying the compiler pipeline. Turboshaft uses a more traditional block-structured control flow, making it easier to reason about, debug, and optimize. It achieves comparable runtime performance to SoN for most code, while significantly reducing compilation time and memory usage.

Key benefits of Turboshaft include:

1. Simpler lowerings: Introducing control flow during lowering is straightforward, allowing the compiler to handle complex language features (like try-catch) without special-case graph structures.
2. Faster scheduling: CFG-based scheduling is linear and predictable, reducing compilation overhead.
3. Easier maintenance: New operators and architectures can be supported more quickly, without the high learning curve of SoN.
4. Better integration with WebAssembly: WebAssembly’s structured control flow maps naturally to a CFG IR, and Turboshaft has been adopted across the entire Wasm pipeline.

Importantly, Turboshaft still supports the speculative optimizations and deoptimization that made Turbofan effective, but with a cleaner design. The frontend of the JavaScript pipeline is being replaced by Maglev, a mid-tier CFG compiler that bridges the gap between the interpreter and Turboshaft, further reducing reliance on SoN.

Current Status and Future

As of early 2024, Turboshaft has fully replaced SoN in the JavaScript backend of Turbofan. The builtin pipeline is gradually being migrated, and the JavaScript frontend will be replaced by Maglev. The only remaining SoN usage is in parts of the builtin pipeline and the legacy frontend, both of which are scheduled for retirement. The V8 team has documented that Turboshaft provides a 10–20% reduction in compilation time across typical workloads, with no measurable regressions in runtime performance.

Looking ahead, the shift to a CFG-based pipeline aligns V8 with the broader compiler community, where CFGs are the norm. This convergence reduces the barrier for new contributors and makes it easier to integrate insights from other JIT compilers. The move from Sea of Nodes to Turboshaft is not a rejection of innovative IRs but a pragmatic evolution: when a more complex representation no longer offers a clear advantage, it’s time to simplify. For V8, that simplification means faster compilation, easier maintenance, and a more sustainable platform for the future of JavaScript and WebAssembly.