V8's Shift from Sea of Nodes to Turboshaft: A New Era for Compiler Intermediate Representations

Introduction

For over a decade, V8's high-performance optimizing compiler, Turbofan, stood out as one of the few production-grade compilers relying on the Sea of Nodes (SoN) intermediate representation (IR). This innovative approach, introduced to replace the older Crankshaft compiler, offered significant flexibility but eventually revealed critical limitations. Since 2020, the V8 team has gradually transitioned away from SoN to a more conventional control-flow graph (CFG) IR called Turboshaft. This article explores the motivations behind this architectural shift and its impact on JavaScript and WebAssembly performance.

V8's Shift from Sea of Nodes to Turboshaft: A New Era for Compiler Intermediate Representations — Source: v8.dev

The Limitations of the Sea of Nodes

The Sea of Nodes IR represented computations and control flow as a unified graph, blurring the lines between data dependencies and control dependencies. While this enabled sophisticated optimizations, it introduced substantial complexity in compiler implementation and maintenance.

Challenges with Optimization and Lowering

One major issue was the difficulty of introducing new control flow during compilation phases. In SoN, the initial graph construction fixed control flow early, making it tricky to lower high-level operations like JSAdd into multiple steps that require conditional branches. For example, distinguishing between numeric addition and string concatenation had to be handled without easily adding extra control flow in later phases.

Performance Cliffs and Bailouts

Compilers using SoN suffered from performance cliffs—small changes in JavaScript code could cause dramatic slowdowns (up to 100x) when specific edge cases triggered bailouts or inhibited optimizations. This unpredictability made it hard for developers to write consistently fast code.

Deoptimization Loops

Another persistent problem was deoptimization loops. Turbofan would speculate optimistically during compilation; when assumptions failed, the engine deoptimized the function. However, re-optimization often repeated the same speculative choices, leading to cycles that wasted CPU cycles and degraded responsiveness.

Support for Try-Catch and Asm.js

The SoN architecture also struggled with structured exception handling (try-catch). Multiple engineers attempted to add proper support but faced insurmountable complexity. Similarly, optimizing asm.js—a precursor to WebAssembly—required handling control flow patterns that SoN handled poorly.

The Birth of Turboshaft

Recognizing these shortcomings, the V8 team designed Turboshaft, a new intermediate representation based on a traditional control-flow graph. Turboshaft explicitly separates basic blocks and edges, making compiler passes simpler to implement and reason about.

Simplifying Compiler Phases

With a CFG, added control flow during lowering becomes straightforward. Operations can be decomposed into sequences of instructions with explicit branches, eliminating the need for workarounds that plagued SoN. This directly supports features like try-catch and intricate string operations.

Reducing Performance Cliffs

Turboshaft’s design minimizes unexpected performance drops. The compiler can more reliably apply optimizations because the IR’s structure aligns better with the actual execution flow. Developers benefit from more predictable performance across different code patterns.

Easier Maintenance and Portability

Unlike Crankshaft’s heavy use of hand-written assembly for each architecture, Turboshaft leverages a more abstract representation that reduces platform-specific code. This accelerates adding support for new architectures and simplifies code reviews.

Current Status and Future Plans

Today, the entire JavaScript backend of Turbofan runs on Turboshaft. WebAssembly also uses Turboshaft throughout its compilation pipeline. However, two areas still rely on Sea of Nodes: the builtin pipeline (being gradually replaced) and the JavaScript frontend (being replaced by Maglev, another CFG-based IR). The long-term goal is complete removal of SoN from V8’s optimizing compiler stack.

Maglev, a new compiler running between the baseline interpreter and Turbofan, will handle the initial optimization of JavaScript hot paths, reducing the workload on Turboshaft and improving overall responsiveness.

Conclusion

V8’s departure from Sea of Nodes marks a pragmatic evolution in compiler design. By embracing a control-flow graph model in Turboshaft, the team addresses longstanding issues with complexity, performance cliffs, and control flow limitations. This change not only makes V8 easier to develop and maintain but also delivers more consistent performance for developers and users alike. As the transition completes, V8 is poised for continued innovation in JavaScript and WebAssembly execution.

Tags: