V8 Compilation Tiers
V8’s tiered execution pipeline, from Ignition bytecode through Sparkplug, Maglev, and TurboFan, trades compile speed for code quality as a JavaScript function proves it is worth optimizing.
A JavaScript function in Chromium doesn’t go straight to the fastest compiler. It starts in the interpreter, gathers evidence about how it behaves, and moves to more expensive code generation only when the runtime feedback justifies the cost. That climb is what V8 calls tiering. It is why a JavaScript-heavy page can be slow on first interaction, faster on the third interaction, and slow again after a shape change forces deoptimization.
What It Is
V8 turns JavaScript into executable code through a sequence of execution tiers. The sequence is not a linear build pipeline that runs every compiler once for every function. It is a runtime policy: start cheap, observe behavior, and spend more compile time only on functions that stay hot enough and stable enough to repay it.
The four tiers are:
| Tier | Role | Tradeoff |
|---|---|---|
| Ignition | Interprets bytecode generated from JavaScript source and records runtime feedback: object shapes, observed types, call targets, and inline-cache state. | Lowest startup cost, lowest execution speed. Every function starts here. |
| Sparkplug | Compiles Ignition bytecode directly to baseline machine code, without a heavy intermediate representation. | Fast compile, modest code quality. V8 introduced it in 2021 to fill the gap between interpretation and full optimization. |
| Maglev | Uses a static single-assignment, control-flow-graph intermediate representation to produce optimized code much faster than TurboFan. | Mid-tier compile cost, good-enough optimized code. It shipped in Chrome M117 to cover functions that deserve optimization before TurboFan would pay off. |
| TurboFan | Produces top-tier speculative optimized machine code for the hottest and most stable functions. | Highest compile cost, highest peak execution speed, and the most exposure to wrong type assumptions. |
Runtime feedback is the constraint that makes the tiers work. Ignition records what the program actually did: which object maps appeared at a property load, which value types reached an arithmetic operation, which function target a call site usually invoked. Sparkplug can run without that feedback because it mostly translates bytecode into equivalent machine code. Maglev and TurboFan depend on the feedback. They generate faster code by assuming the observed shapes and types will continue to hold, then attaching checks that bail out when the assumption breaks.
That bailout is deoptimization. If optimized code was compiled under the assumption that obj.x always reads from a particular object map and a later call passes an object with a different map, V8 abandons the optimized frame, reconstructs an interpreter-compatible state, and resumes in a lower tier. Deoptimization is correctness-preserving. It is also expensive: V8 paid compile cost for code it can no longer use, and the function may need to collect fresh feedback before climbing again.
Two newer names sit beside the four runtime tiers. Turboshaft is the rewritten backend architecture for TurboFan. Since Chrome 120, V8’s CPU-agnostic backend phases run on Turboshaft and compile about twice as fast as before, according to the V8 team’s 2023 year-end update. Turbolev is the in-progress effort to replace TurboFan’s Sea-of-Nodes JavaScript frontend with a Maglev-based control-flow-graph frontend that emits a Turboshaft graph directly. The tier names describe when a function runs; Turboshaft and Turbolev describe how the top tier is being rebuilt underneath.
Why It Matters
“Just-in-time compiler” (JIT) is too blunt for Chromium performance work. A page that spends time in Ignition has a different problem from a page that spends time compiling Maglev code, and both differ from a page that repeatedly deoptimizes out of TurboFan. The first problem may be cold-start execution. The second may be tier-up cost landing on the wrong interaction. The third is usually unstable feedback: object shapes, element kinds, or call targets changing after optimization.
The tier vocabulary also connects JavaScript execution to the Rendering Pipeline. Parse, Style, Layout, and Paint already compete with page JavaScript on the renderer’s main thread. A warm-up path that compiles many functions, or a deoptimization loop that falls back to slower code during input handling, can push the page past the Main Thread Starvation threshold even when Layout and Paint are healthy. A trace that shows V8.Execute is not enough; the tier context tells whether the time is interpreter execution, baseline code, optimized code, compilation, or deoptimization.
For security response, the tiers name the objects the V8 hardening entries protect. V8 Trusted Space stores Ignition bytecode arrays, Code objects emitted by Sparkplug, Maglev, and TurboFan, and the metadata TurboFan uses to validate speculative type assumptions. V8 Bytecode Verifier checks the bytecode that Ignition produces before the interpreter trusts it. V8 Heap Sandbox constrains the heap those generated-code paths operate over. Without the tier names, those defenses read as generic “JIT hardening.” With the tier names, each defense has a precise object and phase.
The operational consequence for downstream products is version and workload sensitivity. Chrome M117’s Maglev launch, Chrome 120’s Turboshaft backend switch, and later profile-guided tiering work all changed how quickly JavaScript-heavy pages reach optimized code and how much CPU they spend getting there. A downstream Chromium-based product that embeds a complex web application can’t treat “V8 performance” as one stable property across releases. Its engineering team has to ask which tiering policy its embedded V8 carries and which workloads that policy helps.
How to Recognize It
The first recognition surface is a performance trace. DevTools Performance captures V8 execution, compile, and deoptimization events under the renderer main thread. A cold trace may show many short functions running under Ignition and Sparkplug before the page reaches steady state. A hot trace may show Maglev or TurboFan compilation work happening off-thread with finalization on the main thread. A pathological trace shows the same function optimizing and deoptimizing repeatedly, which means the runtime feedback never stabilized.
The second surface is V8’s tracing and diagnostic flags. --trace-opt and --trace-deopt show optimization and deoptimization decisions. --print-opt-code prints optimized machine code. The v8 category in chrome://tracing and Perfetto traces surfaces the same family of events in a browser run. These are not ordinary production flags for a downstream product, but they are the diagnostic tools a performance engineer uses to confirm which tier is active.
The source tree also makes the tiers visible. v8/src/interpreter/ holds Ignition. v8/src/baseline/ holds Sparkplug. v8/src/maglev/ holds Maglev. v8/src/compiler/ holds TurboFan and its frontend code, while v8/src/compiler/turboshaft/ holds the newer backend architecture. A change that lands in one of those directories usually names which tier it affects before any benchmark result does.
The user-visible symptom is warm-up followed by stabilization. A JavaScript-heavy editor or dashboard may feel slower on the first open, then faster after repeated interaction as hot functions climb tiers. The opposite symptom is churn: a page runs well, then stutters at the same interaction because a type pattern changed and optimized code deoptimized. That symptom is common in code that sends objects with changing shapes, mixed numeric and string inputs, or arrays whose element kinds change through the same hot function after optimization.
How It Plays Out
A browser-based design tool opens a large project file and feels slow only on the first two interactions. The initial profile shows Ignition execution and Sparkplug baseline compilation dominating startup, followed by Maglev compilation for the project’s hot layout functions. The third interaction is faster because the functions have climbed into optimized code. The engineering move is not to chase Paint or Raster. It is to separate cold-start work from first-input work, pre-warm the hot functions where the product can do so without blocking the user, and avoid object-shape churn that would erase the tier-up benefit.
A dashboard regression appears after a seemingly harmless data-model change. The code now passes two shapes of row object through the same cell-rendering function: one for live rows and one for cached rows. TurboFan optimized the function for the live-row shape, then deoptimized whenever cached rows arrived. The profile shows repeated optimization and deoptimization around the same function. The fix is to normalize the row shape before the hot path or split the function so each call site has stable feedback. The performance bug is not a slow algorithm; it is unstable feedback invalidating optimized code.
A security engineer reads a V8 sandbox advisory that mentions Code objects, bytecode arrays, and type-confusion metadata. The tier vocabulary sorts those objects immediately. Bytecode arrays are Ignition’s product. Code objects come from Sparkplug, Maglev, and TurboFan. Type-assumption metadata belongs to the optimizing tiers. That classification tells which defense layer is relevant: the bytecode verifier for malformed bytecode, trusted space for runtime objects that must survive in-cage corruption, and the heap sandbox for containing the corruption primitive.
The Chromium Blog’s 2024 Speedometer 3 account shows the policy side of the same mechanism. Legacy tiering primarily counted invocations. Profile-guided tiering records prior tier-up behavior, then tiers stable functions earlier on later runs. The mechanism matters more than the benchmark headline: the tiering decision itself is part of the performance model, not an implementation detail below it.
Consequences
Naming the tiers makes JavaScript performance diagnosable. A trace can distinguish cold interpretation, baseline execution, mid-tier optimization, top-tier optimization, and deoptimization. Each diagnosis points at a different move: defer cold code, keep object shapes stable, split polymorphic call sites, or accept that a short-lived function should not be optimized at all.
The vocabulary also prevents false certainty. TurboFan code is not “better” in every situation. It is better when a function is hot enough, stable enough, and long-lived enough to repay its compile cost. Sparkplug’s value is exactly the opposite: it makes many functions faster quickly, with little compile investment, and then gets out of the way for the functions that deserve more. Maglev exists because the gap between those two positions was too wide for real web workloads.
The changing policy is a liability for downstream products. Tiering thresholds, compiler flags, backend architecture, and profile-guided policies change across Chromium releases. A performance conclusion drawn from Chrome 117 doesn’t automatically hold for Chrome 120 or a later V8 with Turbolev enabled. Downstream vendors need traces from their actual build and workload, not borrowed assumptions from another release.
The tiers also complicate security reasoning. Speculative optimization is a performance feature and an attack surface. The same feedback that lets TurboFan remove checks or inline property loads can be wrong, and the wrong assumption is a familiar route to type confusion. V8’s security architecture does not try to pretend this class disappears. It layers containment around it: heap sandboxing, trusted space, bytecode verification, and control-flow hardening.
The durable tradeoff is compile speed against code quality. V8 keeps adding policy and architecture to make that tradeoff less blunt: Sparkplug for cheap baseline code, Maglev for earlier optimized code, Turboshaft for a faster top-tier backend, and profile-guided tiering for better per-function decisions. The tradeoff remains. A runtime that compiles code while the user is interacting has to decide which functions are worth the cost.
Notes for Agent Context
When analyzing Chromium or V8 performance, never collapse Ignition, Sparkplug, Maglev, and TurboFan into a single “JIT” bucket. Identify which tier is active, whether a function is compiling, executing optimized code, or deoptimizing, and whether runtime feedback is stable enough to justify the higher tier.
When generating JavaScript for a Chromium-targeted product, keep hot call sites monomorphic where practical: stable object shapes, stable element kinds, and stable argument types give Maglev and TurboFan useful feedback. Do not “optimize” by mixing object shapes through one hot function unless the trace shows the call site remains stable.
When summarizing V8 sandbox advisories, classify the protected object by tier. Ignition produces bytecode arrays; Sparkplug, Maglev, and TurboFan produce Code objects; Maglev and TurboFan carry speculative type metadata. Map the advisory to bytecode verification, trusted space, or heap-sandbox containment before assigning severity language.
Related Articles
Sources
The V8 team’s Sparkplug: a non-optimizing JavaScript compiler, published 27 May 2021, introduced Sparkplug as the baseline compiler between Ignition and TurboFan and explains why compiling bytecode directly without an intermediate representation keeps startup cost low.
Toon Verwaest, Leszek Swirski, Victor Gomes, Olivier Flueckiger, Darius Mercadier, and Camillo Bruni’s Maglev: V8’s Fastest Optimizing JIT, published 5 December 2023, is the primary public source for Maglev’s Chrome M117 launch, its position between Sparkplug and TurboFan, its SSA/CFG structure, and its compile-speed tradeoff.
The V8 team’s V8 is Faster and Safer than Ever!, published 14 December 2023, records the Chrome 120 Turboshaft backend switch and the year-end benchmark claims that locate Maglev and Turboshaft in the same performance arc.
The V8 team’s Land ahoy: leaving the Sea of Nodes, published 25 March 2025, explains why the top-tier compiler is moving away from Sea-of-Nodes frontend structure toward control-flow-graph representations through Turboshaft and the Turbolev work.
Thomas Nattestad’s Chromium Blog post How Chrome achieved the highest score ever on Speedometer 3, published 6 June 2024, records profile-guided tiering as a Chrome performance optimization contributed by Intel and locates tiering policy inside the Speedometer 3 performance campaign.
Technical Drill-Down
v8/src/interpreter/(pinned0b8b247) — Ignition’s bytecode interpreter, dispatch machinery, and bytecode-generation adjacency.v8/src/baseline/(pinned0b8b247) — Sparkplug’s baseline compiler implementation.v8/src/maglev/(pinned0b8b247) — Maglev’s mid-tier optimizing compiler.v8/src/compiler/(pinned0b8b247) — TurboFan’s compiler infrastructure and the frontend code still being replaced.v8/src/compiler/turboshaft/(pinned0b8b247) — Turboshaft’s backend phases and graph representation.- V8 Maglev blog post — readable design walkthrough for Maglev’s SSA/CFG representation, deoptimization metadata, and register-allocation choices.
- Chromium Blog Speedometer 3 account — public Chrome-side account of profile-guided tiering as a V8 optimization; useful when explaining why tiering policy affects user-visible responsiveness.