Two inner functions are created in the same enclosing function: a short-lived one that reads a huge array, and a small one that is stored globally and never touches that array. Why can the huge array still be retained, and how do you fix it?

## The shape of the trap ```js let handler; function setup() { const huge = new Array(1e6).fill('x'); // used once, briefly const report = () => huge.length; // short-lived consumer report(); handler = () => 'ok'; // tiny, stored forever } setup(); // `handler` mentions nothing from setup - yet `huge` may still be alive ``` Read only `handler` and it looks like it retains nothing. Read the whole function and the mechanism appears. ## One record per scope, not one per closure Every function created inside `setup`'s body captures the same Environment Record — the record for that one invocation of `setup`. The specification models this directly: each function object's `[[Environment]]` slot points at the record that was current when the function literal was evaluated, and both literals were evaluated in the same place. Engines implement this with a heap-allocated *context* object per scope. The optimization they apply is at the granularity of the scope, not of the individual closure: a variable is placed in the context if **any** inner function captures it, and left in registers or on the stack otherwise. So `huge` goes into the context because `report` captures it — and `handler`, pointing at that same context, keeps the context alive, and with it the `huge` slot and the million-element array behind it. The conclusion that surprises people: **the retained set of a closure is determined by what all its siblings capture, not only by what it captures itself.** ## Why engines do it this way Giving each closure a private, precisely-trimmed environment would mean allocating and copying per closure and would break the shared-mutable-binding semantics the language requires — two closures over the same scope must see each other's writes. One shared context is both cheaper and semantically mandatory. Trimming is therefore possible only at the scope level: drop bindings no inner function reads at all. One more sharpening: a **direct `eval`** call in the scope defeats even that trimming, because the engine cannot know which identifiers the evaluated string will reference, so it must keep the whole scope. This is one of the concrete costs of direct `eval`, alongside the more familiar ones. ## The three fixes **Release the binding.** The blunt, local fix: ```js function setup() { let huge = new Array(1e6).fill('x'); const length = huge.length; huge = null; // slot survives, array does not handler = () => 'ok'; } ``` **Move the heavy work into its own function.** Then `huge` is a local of *that* call's scope, and the survivor created in `setup` never shares a record with it: ```js function computeLength() { const huge = new Array(1e6).fill('x'); return huge.length; } function setup() { const length = computeLength(); handler = () => 'ok'; } ``` This is the fix to prefer: it removes the coupling entirely rather than relying on a statement a future refactor can quietly delete. **Create the survivor elsewhere.** If the long-lived callback does not need anything from the heavy scope, define it outside that scope in the first place. ## Diagnosing it by reading Because the survivor's own body gives no clue, the reading discipline is: for any function that outlives its creating call, scan the *whole enclosing scope* and ask what the largest object bound there is. If a scope both allocates something big and produces something long-lived, that pairing is the smell — independent of which closure names what. ## What is guaranteed and what is not Nothing here is a language-level guarantee. ECMAScript defines scoping and reachability but says nothing about when memory is reclaimed, and an engine is free to be smarter (or dumber) about trimming a context. Treat the shared-context behaviour as the realistic model to design against — assume a sibling's capture can retain your data, and write code that does not depend on the optimizer being clever. Where you need a guarantee, restructure the scopes; there is no flag or annotation that promises trimming.