In JavaScript, why is a function's local variable not freed when that function returns, if an inner function it returned still refers to the variable?

## The mechanism: a function remembers where it was born When the engine evaluates a function definition it creates a function object, and that object carries a hidden internal slot the specification names `[[Environment]]`: a pointer to the *Environment Record* that was active at the point the function literal appeared. An Environment Record is the runtime structure that holds one scope's bindings — its parameters, `var`s, `let`s, `const`s and function declarations — plus an `[[OuterEnv]]` pointer to the record of the enclosing scope. A closure is nothing more exotic than that pair: the function's code together with the captured environment pointer. When you later call the inner function, the engine builds a fresh execution context whose scope chain starts at a new record whose outer link is the function's `[[Environment]]`. That is the whole reason the inner function can still resolve an identifier that was declared in a call which returned long ago. ```js function makeReader() { const buffer = new Uint8Array(50 * 1024 * 1024); // 50 MB return function size() { return buffer.length; }; } const read = makeReader(); // makeReader has returned... console.log(read()); // ...yet `buffer` is still there ``` ## Lifetime is reachability, not stack depth The intuition most people import from other languages is that a local variable lives in the call's stack frame and dies when the frame is popped. In JavaScript the frame is popped just the same, but a captured binding does not live in it — it lives in a heap-allocated environment record that the function object points at. Collection is driven purely by reachability: an object survives while it can still be reached from a root (the global object, module scope, a live stack frame, or anything else already reachable). So the chain is: `read` is reachable from module scope → `read.[[Environment]]` is reachable → the `buffer` binding inside it is reachable → the 50 MB typed array it points at is reachable. Nothing in that chain can be reclaimed. ## What you keep is a graph, not a variable The retained set is not "one variable" but everything transitively reachable from the retained bindings. A callback that captures a `config` object keeps `config`, every object `config` references, and so on. This is why the honest one-line summary is "a closure keeps its environment alive", not "a closure keeps a value alive". A single small callback stored in a long-lived place can pin an object graph orders of magnitude bigger than itself. ## Releasing it There is exactly one lever the language gives you: make the retaining reference unreachable. ```js let read = makeReader(); read = null; // the function object, its environment, and the 50 MB become unreachable ``` If the closure is held in an array, a `Map`, or an object property, removing it from there does the same job. Note that `delete` on a variable does not apply — `delete` removes object properties, not bindings — and there is no `free()` in JavaScript. ## What the specification actually promises ECMAScript does not specify garbage collection at all; when memory is reclaimed is an engine decision and is deliberately not observable from ordinary code (the narrow exceptions, `WeakRef` and `FinalizationRegistry`, arrived in ES2021 and are explicitly non-deterministic). Engines are also free to *drop* what a closure provably never reads — a real optimization discussed elsewhere. The guarantee you can lean on is the direction that matters here: anything a live closure could still read will never be collected. ## Why interviewers ask it The question is the counterweight to the usual closure enthusiasm. A candidate who can only say "closures remember their variables" has learned the feature; a candidate who adds "…which means storing that callback extends the lifetime of everything its scope held" has understood the cost. The follow-up is almost always practical: what would you do if that callback lives for the whole process? ```js const handlers = []; function register() { const rows = loadHugeDataset(); // used once handlers.push(() => rows.length); // ...retained forever } ``` The fix in that snippet is to capture only what the callback needs (`const count = rows.length;`) so the dataset is not part of the retained graph at all.