What a closure actually retains

A closure is a function plus a Context pointer

When you write a function that captures an outer variable, you’re not paying for anything magic — you’re just handing the function a pointer it will follow every time it needs that variable. In V8 a function object (a JSFunction) carries two things relevant here: a pointer to its SharedFunctionInfo (the code and ScopeInfo, shared by all instances of that function) and a pointer to its Context — the runtime scope object it was created in. That second pointer is the closure. “Closure” is not a special kind of object; it is the ordinary fact that the function holds a live reference to its defining Context.

Because the function holds the Context, the Context is reachable as long as the function is reachable. And the garbage collector frees only unreachable objects. So the lifetime of every variable stored in that Context is tied to the lifetime of the closure — even variables the closure’s body never mentions.

The trap: siblings share one Context

Here is the part that surprises people. The compiler does not create a separate Context per closure. All functions defined in the same scope capture the same Context object — the one for that scope. If two inner functions live in one scope and the scope has context-allocated variables a and b, then both functions point at the same Context holding both a and b. Keeping either function alive keeps a and b alive.

function makeHandlers() {
  const big = new Array(5_000_000).fill(0); // ~40 MB, context-allocated
  const small = () => 42;                    // captures the SAME Context as below
  const reportSize = () => big.length;       // this one actually uses 'big'
  return small;                              // we return only 'small'...
}
const keep = makeHandlers();
// 'big' is STILL alive: 'small' shares the Context that holds 'big',
// because 'reportSize' (defined in the same scope) forced 'big' to be
// context-allocated. 'small' never reads 'big' — and pins it anyway.

We returned small, a function that computes 42. Yet big cannot be collected. Why? reportSize references big, so the compiler marks big context-allocated and places it in the scope’s one Context. small captures that very Context. As long as keep (the returned small) is reachable, its Context is reachable, and big inside it is reachable. The 40 MB stays.

Reading the retainer in DevTools

This is exactly what a heap snapshot shows. Take a snapshot in Chrome DevTools (or node --inspect), find the big array, and look at its Retainers path. You will see it retained by a system / Context object, which is retained by the closure function. The Context is the smoking gun: when an object’s retainer is a Context you didn’t expect, a closure is holding the scope.

Three ways to break the retention

The fix is always to sever the path closure → Context → big:

1. Null it out. After the last real use, assign big = null. The Context slot now holds null; the 40 MB becomes unreachable and collectable, even though the Context (and small) live on.
2. Don’t context-allocate it. Move big into a narrower scope (e.g. an IIFE or a separate function) so it is not in the Context that the long-lived closure captures. If no surviving closure captures big, it dies with its frame.
3. Separate the scopes. Create the long-lived closure in a scope that simply does not contain the big variable. Build small in one function and big in another; they then capture different Contexts.

All three cuts work on the same principle: if no live reference leads from a reachable closure’s Context to the big object, the GC is free to collect it. Without at least one of these, even big = undefined elsewhere does nothing — the Context slot is the retaining reference.

function makeHandlers() {
  const small = () => 42;            // its own scope, no big in sight
  (function setup() {
    const big = new Array(5_000_000).fill(0);
    process(big);                    // used here, captured by nothing long-lived
  })();                              // 'big' dies when setup() returns
  return small;                      // retains only its (tiny) Context
}