TurboFan''''s speculative engine and the deopt-loop trap

A performance-critical function deopts repeatedly in production — every call triggers a 100ms TurboFan recompile, then deopts again. Your hot path is orders-of-magnitude slower than uncompiled. This is the deopt-loop, and it starts from one misunderstood guard.

TurboFan’s speculative optimisation engine

TurboFan builds a sea-of-nodes graph IR, performs:

• Aggressive inlining — call sites with known targets are inlined, eliminating call overhead and enabling cross-function optimisations.
• Escape analysis — objects that never escape the function scope are stack-allocated or elided entirely (zero allocation, no GC pressure).
• Polymorphic inlining — up to 4 known call targets are inlined with an upfront class-check; the generic slow path handles rare shapes.
• Range analysis — a variable known to be 0..255 stays in a byte register; a loop index known bounded avoids overflow guards.
• Type-narrowing — iterative refinement of types through the graph, enabling tighter machine code.

At every speculative assumption, TurboFan installs a guard instruction: “this is a smi” before arithmetic, “this object has hidden class HCx” before property access. Guard failure means deopt. The cost-benefit: TurboFan code is often 3–10× faster than Maglev when guards hold; when they break, the overhead is worse than never TurboFan-compiling.

The FeedbackVector in depth

Every function has an associated FeedbackVector — a fixed-size array in the GC heap, one slot per IC site (property load, call, binary op). Slots store:

• One hidden class pointer (monomorphic)
• A small array of classes (polymorphic)
• MegamorphicSentinel (given up)

All four tiers read it: Sparkplug reads minimal feedback (type), Maglev reads richer data (class chains, call target frequencies), TurboFan reads everything plus loop trip counts and branch probabilities.

FeedbackVector pollution: a single megamorphic slot explains why V8 cannot keep a function optimised even after deopt-and-reopt cycles. %DebugPrintFeedback(fn) in d8 dumps the vector; inspecting it is the starting point for diagnosing persistent deopt behaviour.

Sparkplug: the JIT that does not optimise

Sparkplug (V8 9.1, May 2021) emits machine code from bytecode in a single linear pass with no SSA, no inlining, no instruction scheduling. For each Ignition bytecode, Sparkplug emits a fixed block of native instructions — approximately 1.5–2× faster than Ignition because the interpreter dispatch loop overhead (table lookup, indirect jump) is replaced by direct execution. Compile speed: ~1ms/kB bytecode. Documented average benefit: 5–15% on real workloads. Purpose: give hot-but-not-hot-enough-for-Maglev functions a speedup without paying Maglev’s compile cost.

Maglev: SSA, but cheap

Maglev (2023) fills the gap between Sparkplug and TurboFan. Pipeline: bytecode → Maglev IR (SSA) → linear-scan register allocator → native code. The IR is simpler than TurboFan’s (no effect chains, no graph rewriting passes); the register allocator is linear scan rather than graph-colouring. Maglev does some speculative optimisation — specialises property loads and arithmetic on observed types — but skips escape analysis, polymorphic inlining, and type-narrowing iteration. Result: ~10ms compile, ~50–70% of TurboFan code quality, correct tradeoff for medium-hot code.

[deoptimizing (DEOPT eager): begin 0x... <JSFunction processItem (sfi = 0x...)> (opt #42) @14, FP to SP delta: 128, caller sp: 0x...]
          ;;; deoptimize at <main.js:42:18>, not a Smi
 bytecode position 14
[deoptimizing (eager): end 0x... processItem  @14 => node=4, pc=0x..., caller sp=0x..., took 0.012 ms]
[marking 0x... <JSFunction processItem (sfi = 0x...)> for non-concurrent optimization]
[compiling method 0x... <JSFunction processItem (sfi = 0x...)> using TurboFan]
[deoptimizing (DEOPT eager): begin 0x... <JSFunction processItem (sfi = 0x...)> (opt #43) @14, FP to SP delta: 128, caller sp: 0x...]
          ;;; deoptimize at <main.js:42:18>, not a Smi
 bytecode position 14