6 ms·
How JavaScript closures are garbage collected
- pfraze 13y agoI'm fairly sure the issue being illustrated here is due to an optimization in how closure scopes are created, which I don't think any of the answers mention (yet). Can't remember where I saw this, but there's a blog-post somewhere in the wild that explains. Slap me if I'm wrong. // scope 1 var someClass = function() {}; function f() { // scope 1, 2 var some = new someClass(); function unreachable() { some; /* scope 1, 2, 3 */ } return function() { /* scope 1, 2, 4 */ }; } window.f_ = f(); Basically, any closures created within scope 2 will share the same parent scope in its scope chain rather than each closure having its own parent. That means any variable in scope 2 that's captured by a child closure (3 or 4) will be included in the other child scopes. In this case, `some` is captured in `unreachable()`, thus it's going to be included in the returned function as well. The returned function is then retained with `window.f_`, and that's the leak. EDIT: for clarity. EDIT2: not the original article I read, but this does cover it: http://www.meteor.com/blog/2013/08/13/an-interesting-kind-of-javascript-memory-leak http://www.meteor.com/blog/2013/08/13/an-interesting-kind-of...
- platz 13y agoThank you!
- paulddraper 13y agoGood find with the meteor.com link! It covers several memory leaks; the last example is the one that is relevant.
- robmcm 13y agoThe mereor permalink didn't work for me, but it's in the list of articles further down the page.
- robmcm 13y agoThe bit that helped most from the meteor post was this: Well, the typical way that closures are implemented is that every function object has a link to a dictionary-style object representing its lexical scope. If both functions defined inside replaceThing actually used originalThing, it would be important that they both get the same object, even if originalThing gets assigned to over and over, so both functions share the same lexical environment.
- paulddraper 13y agoGood quote. That is certainly a simple way to manage things. It isn't the only way (nor the best IMHO), but it is the simplest.
- i_s 13y agoThe author wrote a really short code snippet that demonstrates the problem: function f() { var some = []; while(some.length < 1e6) { some.push(some.length); } function g() { some; } //removing this fixes a massive memory leak return function() {}; //or removing this } If you keep a reference to the results of calling this function, it will keep a reference to the "some" variable, even though it is not needed. He created a page that demonstrates the problem here: https://s3.amazonaws.com/chromebugs/memory.html https://s3.amazonaws.com/chromebugs/memory.html
- e12e 13y agoSo well that it crashed/froze icweasel...
- talles 13y agoAh gc... always behaving as something alive good question by the way
- paulddraper 13y agoUnfortunately, this behavior is common across all major browsers. There is a Chromium bug for it (http://crbug.com/315190 http://crbug.com/315190), but no responses as of yet.
- robmcm 13y agoThis isn't going to be trivial to fix, it would require the vm to provide a different taylored scope to each function.
- paulddraper 13y agoUnfortunately, you are right. I am optimistic, however. IE used to not GC cyclical JS/DOM references. Google Chrome is doing a massive rework of DOM garbage collection with Oilpan. You are right that it is not a trivial change, but there is nothing technically infeasible about GC'ing per closure. I think it is worth it, just as it was worth it for IE to have smarter GC.
- esailija 13y agoThey are not going to "fix it", it is working as intended with the deliberate tradeoff because almost no real world code is affected by it.
- martin-adams 13y agoMaybe it's being kept in case the returned function executes an eval statement which needs the closure ;)