Scopes, contexts, and the scope chain

Lexical scope: a chain decided by where you wrote the code

JavaScript is lexically scoped: the meaning of an identifier is fixed by the textual nesting of functions and blocks, not by who called whom at runtime. When you reference total, the language defines a search: look in the current scope, then its enclosing scope, then the next, up to the global scope. The first declaration found wins. That ordered sequence of enclosing scopes is the scope chain.

The word “search” is doing a lot of damage in most people’s mental models. A linear runtime search of named variables — a dictionary lookup per access — would make every variable read in a closure painfully slow. V8 does not do that for the common case. It splits the work into two halves: a compile-time analysis that figures out where each variable lives, and a runtime structure that holds only the variables that actually need to survive.

ScopeInfo: the compile-time blueprint

Before you can avoid the slow path, you need to understand what V8 builds during compilation — and why that blueprint is the reason most variable reads are cheap. When V8’s parser and bytecode compiler (Ignition) process a function, they build a ScopeInfo object for each scope. ScopeInfo is pure compile-time metadata attached to the function’s SharedFunctionInfo. It records:

• which variables the scope declares (the names),
• which of them are context-allocated — must live on the heap because an inner function captures them — versus stack/register-allocated (purely local),
• the slot index each context-allocated variable occupies,
• the kind of scope (function, block, eval, module, with), and a link to the enclosing ScopeInfo.

Crucially, the compiler can usually resolve a variable reference to a fixed pair: (context depth, slot index). “The variable total is two scopes out, at slot 3.” That resolution is baked into the bytecode as a LdaContextSlot-style instruction. No name lookup happens at runtime — it is an array index into a known object at a known depth.

Context: the runtime scope chain

At runtime, the scopes that must outlive their stack frame are materialised as Context objects. A Context is a small heap object — internally a fixed-size array (a FixedArray flavour) — that holds the context-allocated variables of one scope, plus a pointer to its outer Context. That chain of outer pointers is the runtime scope chain.

Three things follow, and they govern everything in this unit:

1. Only captured variables go in a Context. If the compiler can prove a variable is purely local — declared, used, and never referenced by any inner function — it stays in a CPU register or on the stack and is never heap-allocated. It vanishes when the frame returns. No closure can reach it because none was created over it.
2. A Context is keyed by slot, not by name. Reading total two levels out is: dereference outer, dereference outer again, load slot 3. Fixed work, no hashing.
3. The global scope is special. It is the global object (globalThis) plus a script context that holds top-level let/const. Top-level var and function declarations become properties on the global object; top-level let/const live in the script context as cells. Global reads therefore go through a cell or a property load, not a Context slot, and are cached by inline caches the same way object property reads are.

Together, rules 1 and 2 mean that the only variables paying the heap-allocation price are the ones an inner function actually observes — everything else is free. Rule 3 is why top-level module code has subtly different access costs from inner function code; it is worth knowing when you move hot reads to module scope expecting a speedup.

Why the fast path exists — and what destroys it

The whole optimisation rests on the compiler knowing the layout statically. Two language features break that guarantee and force V8 onto a slow, name-based path:

• with (obj) injects an object whose properties are not known until runtime, so any identifier inside might resolve to a property of obj. The compiler cannot pre-compute a slot; it must emit a dynamic lookup that checks the object first. This poisons the scope for optimisation.
• Sloppy-mode eval can declare new variables in the calling scope (e.g. an eval of var x = 1). Because the compiler cannot know what names eval will introduce, it must keep the scope dynamic — variables can no longer be resolved to fixed slots, and the enclosing function often cannot be optimised well.

Strict mode neutralises the eval case: eval in strict mode gets its own scope and cannot leak declarations outward, so the surrounding scope stays statically analysable. This is one of the concrete performance reasons strict mode exists.

function fast(rows) {
  let total = 0;                 // captured by the arrow -> context-allocated
  rows.forEach(r => total += r); // 'total' resolves to (depth 1, slot 0)
  return total;
}

function slow(rows, cfg) {
  with (cfg) {                   // every identifier below is now dynamic
    let total = 0;               // V8 cannot prove where 'limit' comes from
    rows.forEach(r => { if (total < limit) total += r; });
    return total;
  }
}