I didn't want to go into implementation details as they'd complicate matters :D What you're seeing here is the big difference between specification language an

I didn't want to go into implementation details as they'd complicate matters :D What you're seeing here is the big difference between specification language and implementation - the major JS engines perform free variable analysis and only put variables that are actually captured into the activation object. This means in that in the example `bigArrayBuffer` is simply never stored on or referenced by any object and becomes unreachable the moment demo() returns. Engines can do this because it's essentially unobservable (though the addition of weak references technically undermines this claim, mercifully no one has yet decided that the existence of a closure that _could_ hold an object should be required to). Anyway, the big reason for performing free variable analysis is not to save memory/prevent space leaks as discussed in this article, but to make the function run faster. The first (and biggest) thing you win is that if nothing is captured in a function with closures you don't have to create the lexical environment object: function my_sort(arr) { ... <imagine there are some variables or something> ... return array.sort((a,b)=>{ if (a<b) return -1; return 1}) } There is a lot of code that uses non capturing closures like this, but without doing any free variable analysis the my_sort function would have to allocate a new lexical environment object on every call, even though nothing is actually captured. That environment object allocation was the bit that was expensive enough to warrant doing the free variable analysis when I implemented it in JSC - the time required to perform the free variable analysis is less than the time spent allocating and collecting unnecessary lexical environment objects. As a bonus once you have performed the capture analysis you can also use that information for an bunch of other low cost/complexity perf improvements as well.