From Sea of Nodes to Turboshaft: V8's Evolution in Compiler Intermediate Representations

Introduction

For over a decade, V8's optimizing compilers have shaped JavaScript performance on the web. While the Sea of Nodes (SoN) intermediate representation (IR) in Turbofan was a pioneering approach, V8 is now transitioning to a more traditional control-flow graph (CFG) IR called Turboshaft. This article explores the reasons behind this shift, from the limitations of the earlier Crankshaft compiler to the design decisions that led to Turboshaft's adoption across V8's JavaScript and WebAssembly pipelines.

From Sea of Nodes to Turboshaft: V8's Evolution in Compiler Intermediate Representations — Source: v8.dev

The Origins: Crankshaft's Limitations

Twelve years ago, in 2013, V8 relied on a single optimizing compiler: Crankshaft. Based on a CFG IR, Crankshaft initially delivered impressive speedups. However, as the team added features and optimized for more scenarios, technical debt accumulated, revealing several critical flaws.

Hand-Written Assembly Overhead

Crankshaft contained a large amount of manually written assembly code. Every new IR operator required explicit assembly implementations for each of V8's four supported architectures (x64, ia32, arm, arm64). This not only increased development time but also made the codebase brittle and harder to maintain.

Struggles with asm.js and Control Flow

Back then, asm.js was seen as a pathway to high-performance JavaScript. Crankshaft struggled to optimize asm.js effectively because it could not introduce new control flow during lowering. In modern compilers, it's common to start with high-level operations (e.g., JSAdd(x,y)) and later expand them into lower-level branches (e.g., if (x is String && y is String) { StringAdd(x,y) } else { ... }). Crankshaft's fixed control flow made such transformations impossible.

No Try-Catch Support

Supporting try-catch blocks was a major pain point. Multiple engineers spent months attempting to integrate them into Crankshaft—all without success. The inability to handle exceptions limited the compiler's applicability for real-world JavaScript patterns.

Performance Cliffs and Deoptimization Loops

Crankshaft suffered from severe performance cliffs: using certain features or hitting edge cases could cause a 100× slowdown. Moreover, the compiler often fell into deoptimization loops—it would optimize a function with speculative assumptions, then deoptimize when those assumptions broke, only to reoptimize with the same assumptions again. This unpredictability frustrated developers trying to write efficient code.

The Rise of Sea of Nodes in Turbofan

To overcome Crankshaft's shortcomings, V8 introduced Turbofan with a bold design: the Sea of Nodes IR. SoN represented both data and control dependencies as a single graph, allowing more flexible reordering and optimization. For a time, it was one of the few large-scale production compilers to adopt this approach, and it enabled powerful optimizations like global value numbering and scheduling. However, after years of use, the complexity of managing SoN—especially its non-linear control flow and debugging challenges—led the team to reconsider.

Why the Shift Away? The Move to Turboshaft

About three years ago, V8 began replacing Sea of Nodes with Turboshaft, a CFG-based IR. Turboshaft retains the optimization power of SoN but offers a more intuitive representation that aligns with traditional compiler architectures. Key motivations include:

Simpler control flow: CFGs make it easier to reason about basic blocks, loops, and exception handling.
Better debuggability: Developers found SoN graphs hard to trace and debug; CFG outputs are more familiar.
Lower maintenance cost: The CFG approach reduces the cognitive overhead for new contributors and simplifies internal tooling.
Improved pipeline integration: Turboshaft can reuse optimizations from other CFG-based phases, like Maglev, V8's new mid-tier compiler.

Current State: Turboshaft Adoption

As of today, the entire JavaScript backend of Turbofan uses Turboshaft, and the WebAssembly pipeline has fully transitioned. Only two parts of Turbofan still rely on Sea of Nodes: the builtin pipeline (which is being gradually replaced) and the frontend of the JavaScript pipeline (which will be superseded by Maglev). Maglev itself is a CFG-based IR designed for faster, less aggressive optimization than Turbofan, offering a better trade-off between compile time and code quality.

Conclusion

V8's journey from Crankshaft to Sea of Nodes and now to Turboshaft reflects the constant evolution of compiler technology to meet real-world demands. By moving to a CFG-based IR, V8 aims to simplify development, improve performance predictability, and enable future optimizations. The transition is nearly complete, and developers can expect more stable and maintainable JavaScript and WebAssembly compilation ahead.