Deoptimization: falling off the cliff

What deopt actually is

A guard failure (lesson 04) does not crash and does not silently produce a wrong answer. It triggers a deoptimization: V8 abandons the optimised machine code for that function and resumes execution in the Ignition interpreter at the exact bytecode offset corresponding to where the optimised code gave up. Execution continues correctly, just slower. The optimised code is discarded (or marked invalid), and the function falls back to its lower tier; if it stays hot and its feedback stabilises, it can be re-optimised later.

There are two flavours, distinguished by what invalidated the assumption.

Eager deopt happens synchronously when a guard fails at runtime — the function is executing optimised code, hits a CheckMaps / CheckSmi / CheckBounds, the check fails, and control bails out right there. The trigger is local: this call saw a value the speculation didn’t allow. In --trace-deopt it appears as DEOPT eager with a reason like wrong map or not a Smi.

Lazy deopt happens when an assumption is invalidated externally, not by the function’s own execution. You redefine a function the optimised code inlined, mutate a prototype it depended on, add a property to a shared object, or change a global. V8 cannot reach into a frame that may be running, so instead it marks all dependent optimised code for deopt on next entry — the code is “lazily” deoptimised the next time it would be called. In --trace-deopt it appears as DEOPT lazy. The classic cause is monkey-patching: Array.prototype.map = ... after hot code has been optimised against the original.

Frame translation: how it returns cleanly

When the guard fails, V8 must resume in the interpreter — but the two frames speak entirely different languages. The hard part of deopt is that the optimised frame and the interpreter frame are completely different layouts. Optimised code keeps values in machine registers and a packed stack frame, often in unboxed representations (a raw int32, a raw float64). The interpreter expects values in its own register file (the interpreter’s “registers” are stack slots) in their tagged, boxed form. To resume in the interpreter, V8 must rebuild the interpreter’s frame from the optimised one.

It does this with deopt metadata recorded at compile time: for each possible deopt point, TurboFan stores a description mapping every live optimised-frame location (this machine register holds local i, this stack slot holds total, this is an unboxed double that must be re-boxed) to the interpreter register it belongs in. At deopt time the deoptimizer reads that metadata and performs frame translation — it allocates and fills a fresh interpreter frame with every live value put back where Ignition expects it, re-boxing unboxed values, then jumps into the interpreter at the saved bytecode offset. A single deopt’s translation is cheap, on the order of microseconds.

The deopt-loop: the actual catastrophe

One deopt is fine — microseconds of bookkeeping, then the function re-warms with feedback that now includes the surprising case, re-optimises with a broader assumption, and stays optimised. The catastrophe is the deopt-loop: a function is repeatedly fed a shape or type it cannot keep stable, so it optimises, deopts, re-optimises (the function is still hot, so V8 promotes it again), deopts again — forever. Each cycle pays the deopt translation plus a fresh TurboFan compile (tens to hundreds of ms) plus the time spent running in the slow tier in between. A function in a deopt-loop is orders of magnitude slower than if you had simply disabled optimisation with --no-opt.

When you see a function oscillating between optimised and deoptimised state in —trace-deopt, look for one of these recurring patterns — each is a way to make a guard fail on a recurring value:

• Smi overflow — an arithmetic site optimised on SignedSmall produces a value past the Smi range (greater than 2^30-ish), failing CheckSmi every time the big value recurs.
• Shape change / hidden-class divergence — a call site sees objects with diverging maps; CheckMaps fails. Adding properties in different orders, conditional fields, delete.
• Changing a field’s type — a field optimised as Smi later holds a string or object, so loads guarded on the field’s representation deopt.
• Reading arguments in optimised functions — historically forced deopt or blocked optimisation; modern V8 handles many cases but rest parameters are still the safe choice.
• Out-of-bounds or holey access — CheckBounds failing, or transitioning a packed array to holey elements kind.

You diagnose it with --trace-deopt (every deopt with its function, bytecode offset, and reason) and, in d8 under --allow-natives-syntax, %GetOptimizationStatus(fn) to read the function’s tier bits. The browser-track lesson TurboFan’s speculative engine and the deopt-loop trap walks a full trace-and-fix; here the emphasis is the mechanism and the fix pattern: route the pathological value to a separate slow path before the hot block so the fast path stays type-stable.