Related to yesterday’s post, I just caught up on the comments to Peter Gurevich’s (MS IE Performance PM) guidance to avoid using closures in IE. Matt Kruse had a perfect, concise response which I feel compelled to quote here verbatim:
Closures don’t cause memory leaks.
Browsers that have garbage collection bugs (IE6) and continue to retain those bugs in new versions (IE7) cause memory leaks.
Closures are an extremely powerful and useful programming technique. It’s unfortunate that you would recommend against their use simply because your browser has a bug that causes a memory leak.
A huge amount of time has been spent by the js community to detect, resolve, and work around these IE memory leaks. It’s too bad this was required, and will continue to be required as long as MS refuses to fix the problem.
Hopefully IE’s market share will continue to drop and we can begin to ignore these memory leaks because every other browser out there handles closures just fine.
+1.
Right on the money!
MS is not about to ‘fix the problem’ because it is not really a problem.
The ‘bug’ as I understand it only occurs when using scriptable COM objects within Javascript, and is more than likely un-fixable. The work-around (if you can call it that) is not to use scriptable COM objects within your javascript.
Hardly a showstopper.
No Andrew, IE leaks memory routinely, just in the course of writing normal Javascript/DOM code.
See the folllowing:
http://www.crockford.com/javascript/memory/leak.html
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/IETechCol/dnwebgen/ie_leak_patterns.asp
http://alex.dojotoolkit.org/?p=526
PS – I’m not even sure what a “scriptable COM object” is. I know the pre-IE7 XmlHttpRequest object was an ActiveX object in IE, and there’s some relationship between COM and ActiveX – could you provide some other examples?
The DOM in IE is implemented via “scriptable COM objects”, for some value of those words. COM uses reference-counting without cycle collection, JS must hold strong references to DOM objects, and the DOM window object must strongly reference JS objects, so the bug is inevitable given the design.
Mozilla has had similar but less frequently encountered leaks due to cycles in our JS object and XPCOM reference-counted object graph. These have been fixed over the years in specific and more generic ways. The latest fix in the open source “trunk” uses a single cycle collector based on http://citeseer.ist.psu.edu/532569.html and it thereby eliminates a lot of more specific cycle-breaking and -collecting code.
In fixing the bugs we’ve faced due to lack (until now) of generic cycle collection capability in XPCOM, we have never claimed that closures are the problem and the fix is not to use them. That’s just so wrong on so many levels, I’m surprised that MS tried it out. Thanks for holding their feet to the fire.
/be
BTW, I am sure that MS could implement something like the Bacon and Rajan algorithm (modulo patent licensing, if IBM were to require one ;-)). Why don’t they? Browser implementors are supposed to work harder, so that web developers don’t have to stand on their heads with workarounds or be told not to use fundamental language features. Anyway that is our philosophy at Mozilla.
/be