Speculation and guards

Optimism, protected

The previous lessons established the inputs: feedback says “this site always saw map M and Smi operands”, and TurboFan can specialise on that. But “always saw” is a statement about the past. JavaScript is free to hand the function something different on the next call. Speculative optimisation resolves this tension with a simple contract: assume the observed types, emit code that is only valid under that assumption, and protect every assumption with a guard that checks it cheaply before the fast code runs.

A guard is a tiny instruction sequence that tests the assumption and, on failure, transfers control out of the optimised code entirely (a deopt — lesson 05). The key property is asymmetry: when the guard passes — the overwhelmingly common case for stable code — it costs almost nothing (a compare and a not-taken branch), and the code behind it is maximally fast because it can assume the type with no further checks. The cost of correctness is paid only on the rare failing path.

The guards you will see in --trace-deopt reasons:

• CheckMaps — “this object still has hidden class M”. Gates a property load/store at a fixed offset. Failure reason: wrong map.
• CheckSmi / CheckNumber — “this value is a small integer” / “is a number”. Gates integer or float64 arithmetic with no tag checks or boxing. Failure reason: not a Smi, not a heap number.
• CheckBounds — “this index is within the array’s length”. Gates a raw element load with no bounds re-check inside the loop. Failure reason: out of bounds.
• CheckString, CheckInternalizedString, CheckHeapObject, and friends — similar guards for string and pointer assumptions.

Inlining: fusing guards and bodies

Ask yourself: if the optimiser can’t see past a call boundary, what happens to a guard the caller already proved, but the callee duplicates? Without inlining, you pay for it twice. A function call is a barrier: the optimiser can’t see across it, and the call itself costs a frame setup. Inlining removes the barrier for small, hot callees whose feedback names a known target. TurboFan splices the callee’s graph into the caller, and now the callee’s guards and the caller’s guards live in the same scope. The wins compound:

• A CheckMaps the caller already proved is not repeated inside the inlined body (redundancy elimination across the inline boundary).
• The callee’s pure computation can be scheduled together with the caller’s, hoisted out of shared loops, common-subexpressioned.
• Escape analysis (next) can now see that an object the callee allocates and returns never actually escapes the combined function.

Polymorphic inlining handles up to ~4 known targets with an upfront map check that dispatches between the inlined bodies; beyond that the site is megamorphic and the call stays a generic, uninlined call.

Escape analysis: deleting the allocation

This is the optimisation that most surprises people, because it makes objects free. Escape analysis asks of each allocation: does any reference to this object escape the function — stored into a field that outlives the call, passed to a callee that might retain it, returned? If the answer is no — the object is purely a local scratchpad — TurboFan performs scalar replacement: it deletes the allocation entirely and replaces the object’s fields with ordinary SSA values that live in registers.

Consider a hot distance computation that builds a temporary point:

function dist(ax, ay, bx, by) {
  const d = { x: ax - bx, y: ay - by }; // temp object, never escapes
  return Math.sqrt(d.x * d.x + d.y * d.y);
}

Without escape analysis, every call allocates d on the heap, writes two fields, reads them back, and leaves garbage for the GC. With escape analysis, TurboFan proves d never escapes dist, deletes the allocation, and treats d.x and d.y as two register-resident values. The emitted code has zero heap allocation, no field stores, no field loads, and produces no GC pressure — the object existed only in the source text, not in the running machine code. This is enormous for the temporary points, iterators, options bags, and destructuring intermediates that pervade real code: written for clarity, compiled to nothing.