4 ms·
My understanding of the things that catch people out are things like: function f(){ let a = {}; return function(){}; } In all (IIRC) m
by gsnedders 8y ago
My understanding of the things that catch people out are things like:
function f(){
let a = {};
return function(){};
}
In all (IIRC) major implementations, the object allocated for `a` will be held on to after the function returns because it exists in the lexical scope of the function returned (even though it isn't—and never can be—reached, as static analysis can prove).
Basically all the other bugs I'm aware of are cases of C++ code not treating things as roots when necessary, mostly in DOM code.
- codefined 8y agoShould this be defined as a bug or simply browsers lacking an optimisation trick? In my view it's the latter. The result is the same, the only difference is it's slightly slower to keep "a" around.
- jhallenworld 8y agoI'm finding it impressive that the compilers even attempt to implement this optimization.
- gsnedders 8y agoIt's not that hard to roughly approximate: does an enclosing scope reference this variable or does an enclosing scope contain a direct eval call? (You also have cases where you don't know for sure, especially in the presence of the with statement, but then you just assume it is referenced.) If no enclosing scope references or maybe references it, you can treat it differently to those that are referenced. You don't even need to do actual escape analysis to get 99% of the cases.
- ZenPsycho 8y agoV8 does actually check if the outer variables are referenced by the inner function. There's a misconception amongst a disturbing number of programmers that it's impossible to memory leak in a garbage collected language. For some reason I've found this particularly prevalent amongst C# developers, but no language community is immune from it. In truth there are myriad ways to very casually and accidentally create pools of references that can't be garbage collected. I'll leave finding these as an exercise for the reader to google. here's an old article by Douglas Crockford about a particular memory leak in IE's garbage collector that persisted for a very long time: https://crockford.com/javascript/memory/leak.html https://crockford.com/javascript/memory/leak.html
- deleted 8y ago[deleted]
- gsnedders 8y agoRight, that sort of bug in IE is one of the more common types: not properly tracing through C++ objects. It isn't, per-se, a bug in the JS VM, given the JS VM's GC is merely acting on what the external code tells it (especially given IE used a separate heap for DOM objects).
- earenndil 8y agoWhat if the internal function calls eval?
- gsnedders 8y agoIn the simple case in my parent comment? If it's a direct eval call, then the VM has to assume it'll reference every possible variable, and has to keep them around as a result.