V8's optimizing compiler Turbofan was known for using the Sea of Nodes (SoN) intermediate representation, a rare choice in production compilers. However, over the past three years, the team has been phasing out SoN in favor of a more traditional Control-Flow Graph (CFG) IR called Turboshaft. This transition has already reshaped the JavaScript and WebAssembly compilation pipelines. Below, we explore the reasons behind this shift, the history of V8's compilers, and what the future holds.
What is the Sea of Nodes and why has V8 been moving away from it?
The Sea of Nodes is an intermediate representation (IR) that flattens control flow and data dependencies into a single graph, allowing flexible optimizations. V8's Turbofan compiler used it for over a decade. However, the team began transitioning to Turboshaft, a CFG-based IR, about three years ago. The main drivers were complexity and maintenance burden. SoN's flexibility came at a cost: the graph could become tangled, making it hard to reason about code paths, introduce new optimizations, or debug. Turboshaft's linear CFG is simpler to work with, enabling faster iteration and better performance predictability. By now, the entire JavaScript backend of Turbofan runs on Turboshaft, with only the builtin pipeline and the frontend still relying on older SoN components—those are being replaced by Turboshaft and the new Maglev compiler, respectively.
What was Crankshaft and what issues did it face?
Crankshaft was V8's first optimizing compiler, launched in 2013. It used a CFG-based IR, but over time it accumulated technical debt. Key problems included: excessive hand-written assembly code for each new operator across four architectures (x64, ia32, arm, arm64); inability to introduce control flow during lowering (e.g., converting JSAdd(x,y) into a conditional string addition was impossible); no support for try-catch blocks despite months of effort; severe performance cliffs that could cause 100× slowdowns; and deoptimization loops where functions kept reoptimizing with the same speculative assumptions. These issues made Crankshaft brittle and hard to evolve, prompting the development of Turbofan with its Sea of Nodes IR.
How did Sea of Nodes address Crankshaft's limitations?
The Sea of Nodes (SoN) was designed to overcome Crankshaft's rigidity. By merging control and data flow into a single graph, SoN allowed optimizations to reorder operations, introduce new control flow during lowering (like adding implicit type checks), and support try-catch constructively. It reduced the need for per-architecture assembly templates by leveraging a more abstract representation that could be lowered generically. SoN also enabled speculative optimizations with graceful deoptimization, reducing the risk of performance cliffs. However, while SoN solved Crankshaft's immediate problems, it introduced its own complexities—such as graph complexity and debugging difficulty—that eventually led to the search for a simpler alternative.
What were the disadvantages of Sea of Nodes that led to Turboshaft?
Despite its power, the Sea of Nodes had several downsides. The flat graph structure made it challenging to track control flow, especially when debugging or adding new passes. The lack of a clear separation between control and data dependencies increased cognitive load for compiler engineers. Performance optimization was harder because the graph could become huge and intertwined. Additionally, SoN made it difficult to implement certain classical compiler techniques that rely on explicit CFGs, such as precise liveness analysis or register allocation. Over time, the V8 team realized that a more traditional CFG IR could offer comparable optimization opportunities with far less complexity, leading to the creation of Turboshaft.
What is Turboshaft and how does it differ from Sea of Nodes?
Turboshaft is a new IR that returns to a Control-Flow Graph structure, similar to Crankshaft but with modern design. It represents the program as a sequence of basic blocks connected by edges, with explicit control flow. Data dependencies are expressed within each block. This simplicity makes Turboshaft easier to understand, debug, and optimize. While SoN allowed arbitrary mixing of operations, Turboshaft enforces a linear order, which simplifies passes like instruction selection and register allocation. Despite this, Turboshaft retains the ability to introduce control flow during lowering and supports speculative optimizations with deoptimization. The result is a compiler that is both performant and maintainable, with lower engineering overhead.
What is the current status of the transition from Sea of Nodes to Turboshaft?
As of now, the JavaScript backend of Turbofan has fully adopted Turboshaft. The WebAssembly pipeline also uses Turboshaft exclusively. Two areas still employ Sea of Nodes: the builtin pipeline (which handles intrinsics like Math.sqrt) and the frontend of the JavaScript pipeline (parsing and initial IR generation). The builtin pipeline is being incrementally replaced by Turboshaft, while the frontend is being superseded by Maglev, a CFG-based baseline compiler. Once these migrations complete, Sea of Nodes will be entirely phased out. The transition has already improved developer productivity and compiler performance.
What lessons can other compiler projects learn from V8's experience?
V8's journey offers several insights. First, choose an IR that matches your team's size and expertise—complex IRs like Sea of Nodes can be a liability if the team can't maintain them. Second, prioritize debuggability and simplicity; a simpler IR can accelerate development and reduce bugs. Third, be willing to replace core components when technical debt outweighs benefits. V8’s shift from Crankshaft to Turbofan and then to Turboshaft shows that even successful compilers need periodic modernization. Finally, incremental migration (as done here) reduces risk. For projects considering similar transitions, starting with a clear understanding of current pain points and a well-scoped replacement plan is crucial.