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

Introduction

V8, Google’s high-performance JavaScript engine, has long been at the forefront of compiler innovation. One of its most notable features was the use of a Sea of Nodes (SoN) intermediate representation (IR) in Turbofan, V8’s end‑tier optimizing compiler. However, starting about three years ago, the V8 team began migrating away from SoN toward a more traditional control‑flow graph (CFG) IR called Turboshaft. Today, Turboshaft powers the entire JavaScript backend of Turbofan, and the WebAssembly pipeline has also fully adopted it. Only two parts of Turbofan still rely on SoN: the builtin pipeline (which is gradually being rewritten to use Turboshaft) and the frontend of the JavaScript pipeline (which is being replaced by Maglev, another CFG‑based IR). This article explores the motivations behind V8’s departure from the Sea of Nodes.

The Origins of Turbofan and Sea of Nodes

Twelve years ago, in 2013, V8’s sole optimizing compiler was Crankshaft, which used a CFG‑based IR. While Crankshaft delivered significant performance improvements, it had several critical limitations that eventually led the V8 team to create a new compiler:

• Excessive hand‑written assembly code. Each time a new IR operator was added, its translation to machine code had to be manually written for all four officially supported architectures (x64, ia32, arm, arm64).
• Difficulty optimizing 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 and could not be introduced later. This was a major obstacle, because many optimizations require breaking high‑level operations (e.g., JSAdd(x, y)) into lower‑level operations that may involve conditional branches (e.g., checking if both operands are strings).
• Try‑catch support was absent and proved extremely challenging to add—multiple engineers spent months without success.
• Performance cliffs and bailouts. Using a certain feature or encountering an edge case could cause a hundred‑fold slowdown, making it hard for developers to write predictable code.
• Deoptimization loops. Crankshaft would re‑optimize a function with the same speculative assumptions even after a deoptimization, leading to repeated failures.

To overcome these issues, the V8 team created Turbofan with a Sea of Nodes IR. SoN allowed a more flexible representation where nodes could be reordered and combined without being constrained by a fixed control flow, making it easier to handle complex optimizations and support features like try‑catch.

Why Leave the Sea of Nodes?

Despite solving many of Crankshaft’s problems, SoN introduced its own challenges:

Complexity and Maintainability

Sea of Nodes is a relatively rare IR design. Its graph‑based nature makes it powerful but also difficult to understand, debug, and extend. The V8 team found that the mental overhead of working with SoN slowed down development and made the compiler harder to maintain over time.

A Simpler Alternative Emerges

Advances in compiler techniques and V8’s own experience showed that a well‑designed CFG could now achieve comparable optimization quality while being far simpler. Turboshaft, a modern CFG IR, was developed to offer a cleaner, more modular structure. It allows the team to add new optimizations and backend support more quickly.

Alignment with Other Pipelines

V8’s other compilers—Maglev (a mid‑tier compiler) and the WebAssembly pipeline—are also based on CFGs. Moving Turbofan to a CFG IR creates a more unified infrastructure, reducing duplication and easing integration across the engine.

The Transition to Turboshaft

The migration has been gradual but steady. Over the past three years, the V8 team has systematically replaced SoN‑based components with Turboshaft:

• JavaScript backend: All optimizing passes for JavaScript now use Turboshaft.
• WebAssembly: The entire pipeline—from frontend to backend—runs on Turboshaft.
• Builtin pipeline: Still partially SoN, but being incrementally ported to Turboshaft.
• JavaScript frontend: Being replaced by Maglev, which is CFG‑based and complements Turboshaft.

This phased approach allows the team to validate each change carefully, ensuring no regressions in performance or correctness. Early results show that Turboshaft not only simplifies the codebase but also delivers competitive compile times and generated code quality.

Current Status and Future

As of now, the majority of Turbofan’s JavaScript optimizations are handled by Turboshaft. The remaining SoN parts are on a clear path to replacement. The V8 team expects to eventually remove all Sea of Nodes code, leaving a unified CFG‑based compiler stack. This will make future development faster and less error‑prone, benefiting both JavaScript and WebAssembly workloads.

Conclusion

V8’s journey from Crankshaft to Turbofan’s Sea of Nodes and now to Turboshaft reflects the engine’s continuous evolution. The shift back to a control‑flow graph IR might seem like a step backward, but it is actually a forward‑looking move: it prioritizes maintainability, developer productivity, and long‑term adaptability. By leaving the Sea of Nodes, V8 is navigating toward a clearer and more efficient future for its entire compilation pipeline.