Scope analysis & variable allocation

Where variables live is decided early

Scope analysis is the compile-time pass that builds a scope tree, binds identifier references to declarations, and records enough information for the engine to choose where each variable will live before ordinary execution starts.

The language-level lessons already covered Scope, Closures, Execution contexts, Hoisting, Stack & heap, eval, and Strict mode. This lesson is the engine-level view: how those rules become a storage plan.

Lexical scoping means most variable references can be resolved from the written shape of the program. A parser or scope analyzer builds scopes for functions, blocks, catch clauses, modules, and classes. Then each identifier reference is bound to the nearest matching declaration, or marked global/unresolved.

1function priceLabel(price) {2  const currency = "₹";3  const rounded = Math.round(price);4  return currency + rounded;5}6 7console.log(priceLabel(19.4));

The references to price, currency, and rounded do not need runtime guessing. The analyzer can point each one at a declaration before the first call.

function makeCounter() {
  let count = 0;
  const label = "jobs";
  return function next() {
    count += 1;
    return label + ":" + count;
  };
}

The playground is intentionally smaller than V8, but it is real code: it uses acorn and acorn-walk to parse learner code, build a scope tree, resolve identifiers, and classify variables.

V8's public docs describe a compile-time Scope that tracks declarations, references, and the allocation decision. A variable that never has to outlive the call can use fast frame or register-style storage. A variable captured by an inner function needs heap storage in a Context object.

The V8 blog post Blazingly fast parsing, part 2: lazy parsing calls this the variable allocation problem: the engine must know whether a variable referenced by an inner function is stack-allocated or context-allocated. V8's runtime scope docs name the related objects: Scope, ScopeInfo, and Context.

A local variable normally dies when its function returns. A closure changes that if an inner function can read or write the local later. V8 creates a closure object that points to code and to the current Context, the heap object holding the captured slots it may need.

1function makeCounter(label) {Run2  const scratch = label.trim();3  let count = 0;4  return function increment() {5    count += 1;6    return scratch + ":" + count;7  };8}9 10const next = makeCounter(" jobs ");11console.log(next());12console.log(next());

Run the closure itself and you can see the result of that allocation decision: the returned function uses the same captured bindings on each call.

1function makeCounter(label) {2  const scratch = label.trim();3  let count = 0;4  return function increment() {5    count += 1;6    return scratch + ":" + count;7  };8}9 10const next = makeCounter(" jobs ");11console.log(next());12console.log(next());

V8 does not keep the whole outer scope alive just because a closure exists. It captures the variables the inner functions need. But all closures created by the same outer call can share one Context. If one slot contains a large object and any sibling closure remains reachable, that Context and the object remain reachable too.

1function buildWidgets() {2  const bigConfig = { theme: "dark", cache: new Array(1000).fill("data") };3  let clicks = 0;4 5  function track() {6    clicks += 1;7    return clicks;8  }9 10  function readTheme() {11    return bigConfig.theme;12  }13 14  return { track, readTheme };15}

That is a practical memory-leak pattern: a listener, timer, or cache keeps one small closure reachable, and the shared Context keeps a big object reachable with it. The later Memory management and Finding memory leaks lessons show how to inspect retained objects.

Static scope analysis works best when syntax tells the whole story. Sloppy direct eval and with break that rule. A sloppy direct eval string can read visible names by text and create a var binding in the caller. A with statement inserts an object into name lookup, so property names can shadow lexical declarations at runtime.

1function demo() {Run2  let local = 1;3  eval("var surprise = local");4  return local;5}6 7function readWith(box) {8  const answer = "lexical";9  with (box) {10    return answer;11  }12}13 14console.log(readWith({ answer: "object wins" }));

1function sloppyDirect() {2  const x = "local";3  eval("var leaked = x");4  return x + " | " + leaked;5}6 7function strictDirect() {8  "use strict";9  const x = "strict local";10  eval("var hidden = 1");11  return x + " | " + typeof hidden;12}13 14globalThis.x = "global";15function indirectEval() {16  const x = "local";17  return (0, eval)("x");18}19 20console.log(sloppyDirect());21console.log(strictDirect());22console.log(indirectEval());

1function readWith(box) {2  const answer = "lexical";3  with (box) {4    return answer;5  }6}7 8console.log(readWith({ answer: "object wins" }));

Strict mode rejects with as a syntax error. Even in sloppy code, prefer explicit property access such as box.answer. It is clearer for humans and gives engines a stable binding story.

The spec talks about lexical environments and environment-record chains. V8 uses compile-time Scope objects, serializes the needed metadata into ScopeInfo, and creates runtime Context objects when a scope needs context-allocated slots. Contexts link to previous contexts, forming a context chain.

1function outer() {2  let total = 0;3  return function middle(step) {4    let label = "count";5    return function inner() {6      total += step;7      return label + ":" + total;8    };9  };10}11 12const inner = outer()(2);13console.log(inner());14console.log(inner());

The V8 faster class features blog also uses this terminology when private methods are accessed: V8 walks the context chain, reads a statically known slot from the found context, and uses that value to complete the access. The same idea matters for closure variables.

node --print-bytecode --print-bytecode-filter=inner captured.js
# Node 22.23.1 (V8 12.4): look for LdaCurrentContextSlot,
# StaCurrentContextSlot, LdaContextSlot, StaContextSlot, and PushContext.

function captured() {
  let x = 0;
  return function inner() {
    x += 1;
    return x;
  };
}
const f = captured();
f();

function uncaptured() {
  let x = 0;
  x += 1;
  return x;
}
uncaptured();

function outer() {
  let x = 1;
  return function middle() {
    let y = 2;
    return function inner() {
      x += 1;
      y += 1;
      return x + y;
    };
  };
}
const inner = outer()();
inner();

DevTools and real-world memory

Chrome DevTools turns these ideas into clues. When paused, the Scope pane can show groups such as Local, Closure, Block, Script, and Global. Closure entries correspond to captured variables the debugger can expose. Values that were never captured or were optimized away may not be inspectable; DevTools wording can include unavailable or optimized out values depending on Chrome and optimization state.

In production, this is why avoiding eval and with matters beyond style. Static names help engines optimize, and small captured state prevents accidental retention when a closure lives longer than expected.

Common misconceptions

Key takeaways

• Lexical scoping lets engines resolve most names statically from the scope tree.
• Uncaptured locals can live in fast stack/frame/register storage.
• Variables captured by inner functions become context-allocated in heap Context slots.
• Sloppy direct eval and with make lookup dynamic and force conservative optimization.
• ScopeInfo describes context layout; a runtime Context stores captured values.

Up next: Bytecode & interpreters, where those storage decisions show up as bytecode instructions.