Functions & closures inside the engine

The engine view of a function

You already know the language rule: a closure lets a function use variables from where it was created. This lesson looks one layer lower, inside V8 12.4 as shipped with Node 22. We will keep two ideas separate the whole way: JavaScript semantics are the promises your program gets; V8 objects are one engine's strategy for keeping those promises fast.

If you want the language-level story first, use Closures, Function objects, call, apply, and bind, and Arrow functions. Scope analysis explains when V8 can keep variables on the stack versus when it must allocate a context. We build on those lessons instead of repeating them.

Previous in this module: Fast arrays & elements kinds. Next in this module: Prototypes inside the engine.

JSFunction: one object per evaluation

A function literal is the source expression that creates a function, such as function inner() or () => 1. Every time execution evaluates that literal, V8 allocates a fresh JSFunction. That object has identity: two closures can run the same code and still be different objects.

1const sharedFunctionInfo = { name: "inner", parameters: 1, bytecode: "return seed + extra" };Run2let nextFunctionId = 1;3let nextContextId = 1;4 5function evaluateFunctionLiteral(seed) {6  const context = { id: "Context#" + nextContextId, seed };7  nextContextId += 1;8  const jsFunction = {9    id: "JSFunction#" + nextFunctionId,10    shared: sharedFunctionInfo,11    context,12  };13  nextFunctionId += 1;14  return jsFunction;15}16 17const first = evaluateFunctionLiteral(10);18const second = evaluateFunctionLiteral(20);19const third = evaluateFunctionLiteral(30);20console.log(first.shared === second.shared);21console.log(first.id !== second.id);22console.log(first.context.id !== second.context.id);

In the replay, lines 17 through 19 call the same factory three times. Each call creates a new context and a new function object. The important relation is line 20: the three objects point at one shared recipe, but line 21 says the function objects themselves are distinct.

SharedFunctionInfo: the shared recipe

V8's function-architecture document says SharedFunctionInfo stores context-independent data: bytecode, ScopeInfo, source positions, and feedback metadata. That data can be shared because it does not depend on which outer call created the closure.

1function makeClosure(seed) {2  return function inner(extra) {3    return seed + extra;4  };5}6 7const first = makeClosure(1);8const second = makeClosure(2);9%DebugPrint(first);10%DebugPrint(second);

Read the fields in plain language. shared_info names the reusable recipe. context points at the environment for one closure. formal_parameter_count, kind, and source code come from the shared function description.

This is why “function object” can mean two different things in casual conversation. JavaScript code holds the JSFunction. Engine engineers often talk about the heavier shared metadata separately.

Contexts hold closed-over variables

A Context is V8's runtime heap object for variables that must outlive the stack frame that created them. V8's scopes documentation says the compiler decides which variables must be context-allocated; the runtime then creates a FunctionContext when the scope is entered.

1function outer() {2  const big = ["notes", "chart", "photo"];3  const readBig = () => big.length;4  const answer = () => 1;5  return { readBig, answer };6}7 8const closures = outer();Run9console.log(closures.answer());10console.log(closures.readBig());

Line 2 stores big. Line 3 creates a closure that reads it. Line 4 creates a sibling closure that does not read it. V8's real debug output for this shape shows both sibling closures pointing at the same FunctionContext address.

1function outer() {2  const big = ["notes", "chart", "photo"];3  const readBig = () => big.length;4  const answer = () => 1;5  return [readBig, answer];6}7 8const [readBig, answer] = outer();9%DebugPrint(readBig);10%DebugPrint(answer);

What a closure keeps alive

A closure keeps alive what it can reach. In V8, that often means the JSFunction keeps a context alive, and the context keeps every object in its slots alive. This is where closure internals become practical memory knowledge.

1function outer() {2  const big = new Array(1_000_000).fill("invoice");3  const unused = () => big.length;4  return () => 1;5}6 7const keep = outer();8console.log(keep());

1function noSibling() {2  const big = new Array(10);3  return () => 1;4}5 6function withSibling() {7  const big = new Array(10);8  const unused = () => big;9  return () => 1;10}11 12const noContextClosure = noSibling();13const sharedContextClosure = withSibling();14%DebugPrint(noContextClosure);15%DebugPrint(sharedContextClosure);

1function forceCollection() {2  for (let round = 0; round < 20; round += 1) {3    globalThis.gc();4    const pressure = [];5    for (let i = 0; i < 50000; i += 1) pressure.push({ i });6  }7  globalThis.gc();8}9 10function noSibling() {11  const big = { data: new Array(100000).fill(1) };12  return { fn: () => 1, weak: new WeakRef(big) };13}14 15function withSibling() {16  const big = { data: new Array(100000).fill(1) };17  const unused = () => big;18  return { fn: () => 1, weak: new WeakRef(big) };19}20 21(async () => {22  const a = noSibling();23  const b = withSibling();24  await new Promise((resolve) => setImmediate(resolve));25  forceCollection();26  await new Promise((resolve) => setImmediate(resolve));27  forceCollection();28  console.log("no sibling alive", a.weak.deref() !== undefined);29  console.log("with sibling alive", b.weak.deref() !== undefined);30  console.log(a.fn(), b.fn());31})();

For production leak hunting, link this mental model to Memory management and Finding memory leaks. Long-lived listeners, timers, and caches are the usual roots, not the fact that a closure exists.

Feedback cells and many closures

Feedback is runtime evidence the engine collects for optimization: call targets, property shapes, binary-operation hints, and tiering budgets. V8 puts a FeedbackCell between a JSFunction and the full FeedbackVector, so it can allocate feedback lazily and share it in some safe cases.

1function oneFactory(n) {2  return function addOne(x) {3    return x + n;4  };5}6const only = oneFactory(1);7for (let i = 0; i < 40; i += 1) only(i);8%DebugPrint(oneFactory);9 10function manyFactory(n) {11  return function addMany(x) {12    return x + n;13  };14}15const first = manyFactory(1);16const second = manyFactory(2);17for (let i = 0; i < 40; i += 1) {18  first(i);19  second(i);20}21%DebugPrint(manyFactory);22%DebugPrint(first);23%DebugPrint(second);

This is not a rule you need to code around. It explains why the engine can share code and sometimes share feedback while still giving each closure its own captured values. The previous type feedback and inline caches lessons go deeper on the feedback itself.

Bound and arrow functions internally

bind does not edit the original function. It creates a wrapper. V8 prints that wrapper as JSBoundFunction, with fields for the target function, the stored this value, and the stored arguments.

1function total(fee, tax) {2  return this.base + fee + tax;3}4 5const bill = total.bind({ base: 100 }, 20);6console.log(bill(5));7console.log(bill.length);8console.log(bill.name);

1function total(fee, tax) {2  return this.base + fee + tax;3}4 5const bound = total.bind({ base: 10 }, 1);6%DebugPrint(bound);

Arrows are different. They are still function objects, but their kind is ArrowFunction. They have no own this, no own arguments, no own prototype property, and they are not constructors.

1const shop = {2  label: "Kochi counter",3  makeReader() {4    return () => this.label;5  },6};7 8function makeFirst() {9  return () => arguments[0];10}11 12const reader = shop.makeReader();13const first = makeFirst("Asha", "Ravi");14console.log(reader.call({ label: "Mumbai counter" }));15console.log(first());16console.log("prototype" in first);17try {18  new first();19} catch (error) {20  console.log(error.name);21}

1const arrow = () => this;2%DebugPrint(arrow);

For language behavior, revisit call, apply, and bind and Arrow functions. Here the point is the engine representation behind the behavior.

Practical memory and performance habits

Most closures are fine. Use this internals model when a heap snapshot, allocation profile, or performance trace points at a real problem. Then look for long-lived roots: event listeners, timers, caches, promises that never settle, or module-level arrays of callbacks.

1function mountPanel(root, report) {2  const state = { clicks: 0 };3  function onClick() {4    state.clicks += 1;5    report(state.clicks);6  }7  root.addEventListener("click", onClick);8  return () => root.removeEventListener("click", onClick);9}10 11const events = [];12const root = {13  listeners: new Set(),14  addEventListener(_type, fn) { this.listeners.add(fn); },15  removeEventListener(_type, fn) { this.listeners.delete(fn); },16  click() { for (const fn of this.listeners) fn(); },17};18 19const cleanup = mountPanel(root, (count) => events.push(count));20root.click();21root.click();22cleanup();23root.click();24console.log(events.join(","));25console.log(root.listeners.size);

Line 3 creates a small state object. Line 7 registers a callback that closes over it. Line 8 returns a cleanup function. After line 22 runs, the root no longer stores the callback, so the closure and its state can become collectible when nothing else references them.

• Keep captured data narrow: capture an ID or a small summary instead of a whole response object when that is all the callback needs.
• Clean up listeners, timers, observers, and subscriptions when UI or server resources unmount.
• Use heap snapshots to find retainers before changing code; names like Context and JSFunction are clues.
• Measure first for performance. Sharing SFI and feedback details rarely matter unless a profiler says a hot path does.

Common misconceptions

• “A closure copies every variable.” It keeps access through a context; the context contains slots for variables V8 decided must be context-allocated.
• “Every function object owns its own code.” Many JSFunction objects can share one SharedFunctionInfo.
• “If my returned closure does not read a value, it cannot keep it alive.” A sibling closure can force a shared context that the returned closure keeps reachable.
• “Bound functions modify the original function.” They are wrappers with bound target, this, and arguments.
• “V8 internals are JavaScript semantics.” The spec promises lexical behavior; V8's object names are implementation details.

Practice exercises

function makeClosure(seed) {
  return function inner(extra) {
    return seed + extra;
  };
}
const first = makeClosure(1);
const second = makeClosure(2);
console.log(first === second);
console.log(first(10));
console.log(second(10));

function outer() {
  const big = ["notes", "chart", "photo"];
  const readBig = () => big.length;
  const answer = () => 1;
  return { readBig, answer };
}

const closures = outer();
console.log(closures.answer());
console.log(closures.readBig());

function total(fee, tax) {
  return this.base + fee + tax;
}

const bill = total.bind({ base: 100 }, 20);
console.log(bill(5));
console.log(bill.length);
console.log(bill.name);

function makeLabel(prefix) {
  // return an arrow that adds ":" and a name
}

const label = makeLabel("order");
console.log(label("Asha"));

function makeLabel(prefix) {
  return (name) => prefix + ":" + name;
}

const label = makeLabel("order");
console.log(label("Asha"));

function mountPanel(root, report) {
  const state = { clicks: 0 };
  function onClick() {
    state.clicks += 1;
    report(state.clicks);
  }
  root.addEventListener("click", onClick);
  return () => root.removeEventListener("click", onClick);
}

const events = [];
const root = {
  listeners: new Set(),
  addEventListener(_type, fn) { this.listeners.add(fn); },
  removeEventListener(_type, fn) { this.listeners.delete(fn); },
  click() { for (const fn of this.listeners) fn(); },
};

const cleanup = mountPanel(root, (count) => events.push(count));
root.click();
root.click();
cleanup();
root.click();
console.log(events.join(","));
console.log(root.listeners.size);

Check your understanding

Key takeaways

• Every evaluation of a function literal creates a new JSFunction, while V8 can share one SharedFunctionInfo.
• A closure's context is heap storage for closed-over variables; sibling closures from one outer call can share it.
• A returned closure can keep a large value alive through a shared context even when only a sibling closure reads that value.
• Feedback cells and vectors collect runtime evidence; V8 can mark one-closure and many-closures cases.
• Bound functions are wrappers; arrows are function objects with lexical this, no own arguments, and no constructor prototype.

Next: Prototypes inside the engine, where the same map and feedback ideas explain inherited property lookups.