Functions & closures inside the engine

What a function looks like inside the engine

The engine is the program that runs your JavaScript. Chrome and Node use an engine called V8. This lesson uses V8 version 12.4, the one that comes with Node 22.

You may already know what a closure is: a function that can still use variables from the place where it was made. This lesson opens up V8 and shows the objects it builds to make functions and closures work.

Keep two things apart the whole way:

• What JavaScript promises. Every engine must behave this way.
• How V8 keeps that promise. These are V8's own objects and names. Other engines use different ones.

These lessons explain the JavaScript side first: Closures, Function objects, call, apply, and bind, and Arrow functions. Scope analysis explains how V8 decides which variables need a context. This lesson builds on them.

The table lists the four parts you'll meet. Read each row as: "this part, how many there are, and what it holds."

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

A new function object each time

A function literal is the piece of code that makes a function, like function inner() { } or () => 1. Each time JavaScript runs that piece of code, V8 makes a brand-new JSFunction.

So two functions can run the same code and still be two different objects. === on them gives false.

The step-through below is a small model written in plain JavaScript. It acts out what V8 does. It is not V8 itself.

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);

Here is what the model does, line by line:

1. Line 1 makes one shared object for the code. It stands for the SharedFunctionInfo.
2. Lines 17 to 19 call evaluateFunctionLiteral three times, like running a function literal three times.
3. Each call makes a new context on line 6 and a new function object on line 8.
4. Line 20 prints true: all three function objects point to the same shared code.
5. Line 21 prints true: the function objects themselves are different.
6. Line 22 prints true: each function object has its own context.

SharedFunctionInfo: the shared recipe

The SharedFunctionInfo holds everything about a function that is the same for every copy. V8's own design notes list:

• the bytecode: the short instructions V8 makes from your code and then runs;
• the scope info: the names of the function's variables and where each one is kept;
• where the function sits in your source file;
• facts like its name and how many parameters it has.

None of this depends on which outer call made the function. That is why many function objects can share one.

To look inside V8, Node has a special command, %DebugPrint(value). It prints what V8 holds for that value. It only works when you start Node with the --allow-natives-syntax setting, so it never runs in a browser or in normal code.

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);

Lines 7 and 8 call makeClosure twice, so the function literal on line 2 runs twice. Lines 9 and 10 print what V8 holds for each result.

The printout gives each object an address: a number that says where the object sits in memory. Two equal addresses mean one object. Two different addresses mean two objects. The printout shows these lines:

• DebugPrint: is the address of the function object itself.
• shared_info is the address of the shared recipe, the SharedFunctionInfo.
• context is the address of the storage for this one closure's outside variables.
• formal_parameter_count (the number of parameters), kind, and source code come from the shared recipe.

So "the function" can mean two things. Your code holds the JSFunction. The code and facts behind it live in the SharedFunctionInfo, which many functions share.

Contexts hold the outside variables

When a function is called, its local variables usually live in a scratch area for that one call. The engine calls it a stack frame. When the call ends, the stack frame is thrown away.

But an inner function may still need an outer variable after the outer call has ended. V8 can't keep that variable in the stack frame. So it puts it in a Context: a small object in long-lived memory (the heap) that stays as long as something points to it.

Before the code runs, V8 reads it and decides which variables need a context. When the outer function is called, V8 makes the context. For a function call, V8 names it a FunctionContext.

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 the array big. Line 3 makes readBig, which reads big. Line 4 makes answer, which does not read big. Two functions made in the same outer call are called siblings.

In real V8, both siblings point to the same FunctionContext. The code below checks that.

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

The engine frees memory on its own. This is called garbage collection. It frees an object only when nothing your program still uses can reach it. An object that can still be reached is reachable, and it stays in memory.

A closure keeps alive everything it can reach. In V8 that chain often looks like this:

1. Your program holds the function object.
2. The function object points to its context.
3. The context holds every variable that was put in it, even ones this function never reads.

That last point matters for memory, as the next example shows.

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());

The table sums up the three cases from the playground. Read each row as: "when the code looks like this, V8 does this, so this happens to big."

The next code checks this in real V8. noSibling has no inner function that reads big. withSibling has one, called unused, on line 8. Both return () => 1.

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);

In the printout, the first function points to a ScriptContext. That is the context of the whole file, and it holds nothing from noSibling. The second function points to a FunctionContext made by the call to withSibling.

The next code checks whether big really stays in memory. It uses two tools:

• A WeakRef points to an object without keeping it alive. Its deref() method gives back the object, or undefined once the object has been freed.
• globalThis.gc() starts garbage collection right away. It only exists when you start Node with the --expose-gc setting.

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})();

Line 28 prints no sibling alive false: big was freed. Line 29 prints with sibling alive true: the returned function still holds the context, and the context still holds big.

To hunt real memory problems, go on to Memory management and Finding memory leaks. The usual cause is not that a closure exists. It is that something long-lived, like an event listener, a timer, or a cache, still holds the closure.

Feedback cells: notes shared by many closures

While your code runs, V8 takes notes on how it runs. These notes are called feedback. For example:

• which function a call ended up calling;
• what shape of object a property was read from;
• whether a + only ever saw small whole numbers;
• how often the function has run.

V8 uses these notes to make busy code faster. It keeps them in two places:

• A FeedbackVector is the list of notes itself.
• A FeedbackCell sits between the function object and that list. It lets V8 make the list only when the code is used, and share it when that is safe.

The code below makes one factory that creates one function, and a second factory that creates two functions from the same literal. Then it calls each function 40 times, so V8 has something to note. Calling code many times like this is called warming it up.

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);

A factory keeps one feedback cell for the function literal inside it. The cell says whether that literal has made one function so far, or many.

You don't need to change your code because of this. It shows that V8 can share code, and sometimes notes, while still giving each closure its own variables. The type feedback and inline caches lessons explain the notes in more depth.

Bound functions and arrow functions inside V8

fn.bind(thisValue, ...args) makes a new function that always calls fn with that this and those first arguments. It does not change fn. It makes a wrapper: a new function object that stores three things and then calls the original. V8 calls this wrapper a JSBoundFunction. It stores:

• the function to call, as bound_target_function;
• the this value to use, as bound_this;
• the arguments to put first, as bound_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);

In plain words, line by line:

1. Line 5 makes bill. It saves { base: 100 } as this and 20 as the first argument, fee.
2. Line 6 calls bill(5). The 5 becomes tax, so total returns 100 + 20 + 5 and it prints 125.
3. Line 7 prints 1. A function's length is how many parameters it expects. Only tax is still open.
4. Line 8 prints bound total. A bound function's name starts with bound.

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

The printout says JSBoundFunction and shows the three saved parts. The original total is not changed.

Arrow functions are different. They are still function objects, but V8 marks their kind as ArrowFunction. An arrow function:

• has no this of its own. It uses the this of the code around it.
• has no arguments of its own. It uses the arguments of the function around it.
• has no prototype property.
• can't be called with new.

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}

In plain words, line by line:

1. Line 4 makes an arrow inside makeReader. It uses makeReader's this, which is shop.
2. Line 9 makes an arrow that reads arguments[0] of makeFirst.
3. Line 14 tries to give the arrow a new this with .call(). It still prints Kochi counter.
4. Line 15 prints Asha, the first argument passed to makeFirst on line 13.
5. Line 16 prints false: the arrow has no prototype property.
6. Line 18 calls the arrow with new. That throws, and line 20 prints TypeError.

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

The printout shows kind: ArrowFunction and function prototype: <no-prototype-slot>. That means V8 did not even leave room for a prototype.

The table compares the three kinds. Read each row as: "this kind of function, what V8 builds for it, and how it acts."

For how these act in everyday code, see call, apply, and bind and Arrow functions. This section showed what V8 builds behind them.

Habits for memory and speed in real code

Most closures are fine, and you don't need to think about contexts every day. Use this lesson when a tool shows a real problem:

• a heap snapshot, a DevTools list of every object in memory and what keeps it there;
• an allocation profile, which shows where your code makes new objects;
• a performance trace, which shows where time goes.

Then look for something long-lived that still holds a closure: an event listener, a timer, a cache, a promise that never finishes, or a top-level array 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);

In plain words, line by line:

1. Line 2 makes a small state object.
2. Line 3 makes onClick, a closure that uses state.
3. Line 7 adds onClick to root's listeners. Now root holds the closure.
4. Line 8 returns a cleanup function that removes onClick again.
5. Lines 20 and 21 click twice. Line 22 runs the cleanup. The click on line 23 runs no listener.
6. Line 24 prints 1,2, and line 25 prints 0 listeners.

After line 22, root no longer holds onClick. When nothing else points to it, the closure and its state can be freed.

• Keep only what you need in a closure. If a callback only needs an ID, keep the ID, not the whole server response.
• Remove listeners, timers, observers, and subscriptions when a part of the page goes away or a server task ends.
• Find what keeps an object alive in a heap snapshot before you change code. Names like Context and JSFunction are clues.
• Measure speed before you change it. Shared code and shared notes rarely matter unless a profiler points at busy code.

Common misconceptions

• "A closure copies every variable." It doesn't copy them. It points to a context, and the context holds the variables V8 decided to put there.
• "Every function object has its own copy of the code." Many function objects can share one SharedFunctionInfo.
• "If my returned function never reads a value, it can't keep that value alive." A sibling that reads it can put it in a shared context. The returned function keeps that context, and so the value.
• "bind changes the original function." It makes a new wrapper that stores the function, this, and the first arguments.
• "V8's objects are part of JavaScript." JavaScript only promises how closures act. Names like JSFunction belong to V8, and other engines use different ones.

The table puts side by side four ideas that are easy to mix up. Read each row as: "this idea, what it is, and what it is not."

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

• Each time a function literal runs, V8 makes a new JSFunction. Many of them can share one SharedFunctionInfo, which holds the code.
• A Context holds the outside variables a closure still needs. Siblings made in one outer call share one context.
• A returned function can keep a large value in memory through a shared context, even when only a sibling reads that value.
• Feedback is V8's notes on how code runs. A feedback cell records whether a literal made one function or many.
• A bound function is a wrapper that stores the function, this, and the first arguments. An arrow has no this, arguments, or prototype of its own, and can't be used with new.

Next: Prototypes inside the engine. It shows how V8 uses the same kind of notes to find a property on a parent object quickly.