Tuesday, September 18th, 2007

IE’s Memory Leak Fix Greatly Exaggerated

Category: IE

We were all hoping that IE’s memory leaks were fixed, but Joel Webber of the GWT team dug deeper . At first he was excited of course:

When I saw this article, I nearly spilled tea all over the keyboard. They really fixed this issue? You mean I can untangle all the painful code in GWT that works around this issue, diligently cleaning up all its circular DOM references under all sorts of circumstances?

And then he had a gut check:

Before I got too excited, I had to do a little gut-check. Did they really go back and make it possible for their garbage collector to chase references through COM objects? That would be wonderful, but I’m not holding my breath.

And it’s a good thing, because there’s basically no way in hell they did that. In fact, it turns out that all they did was write a little code to sweep the DOM on unload and clean up all the extant circular references on those elements. This means that *all elements not still attached on unload are still leaked, along with the transitive closure over all references Javascript objects*. In even marginally complex applications, that means you’re still going to leak like a bloody sieve!

And finally he tested it with a script to prove that IE still throws out memory all over the shop. Some things are too good to be true.

Come on IE team. For awhile you were out in the open talking to the community, and then you went back into the black hole!

Posted by Dion Almaer at 9:56 am

4 rating from 46 votes


Comments feed TrackBack URI


We wanted to support IE with Java Script Memory Validator but the IE team members change so rapidly (being pulled off one thing onto another) that the people inside Microsoft that were trying to help us could no longer make it happen. If Microsoft would talk to us we could have a working memory tool for IE in weeks.


Comment by Stephen Kellett — September 18, 2007

Only loosers still use IE nowadays

Enjoy the web, there is plenty to do if your browser let you

Comment by scriptkiddie — September 18, 2007

IE is not the only one that has memory leak problem. If you watch ff memory usage while interacting with ajax app (eg. ExtJS) you will also see that the usage is increasing. It does release some of used memory, but apparently some are still stuck and can’t be released.

Comment by Georg Miller — September 18, 2007

Safari also has memory leaks, and I doubt Opera doesn’t. The problem though is that IE’s developed in an environment that precludes community help improving the browser.

Comment by Trevor — September 18, 2007

we got lucky in Dojo 0.9 that we were testing for memory leaks and spotted this early. We re-enabled the memory leak prevention code just before release for IE 7…we’re still finding new leakage patterns. For things to be cleaned up correctly, we have to ensure that things don’t actually get destoryed, but rather added to the visible DOM just before unload (as the pattern describes would imply). Real DOM cleaning code still has to be part of every toolkit. It’s effing insane that we’re still doing this shit in 2007. IE’s COM dependency is going to be the death of us all.

Comment by Alex Russell — September 18, 2007

Told you so :p
We didn’t change a thing in ASP.NET Ajax after this hotfix, which is not fixing anything for all practical purposes. As Alex says, the cleanup code is pretty much still needed in every toolkit.

Comment by Bertrand Le Roy — September 18, 2007

Wow, what happened to automatic garbage collection?

Comment by Andy — September 18, 2007


Can you elaborate a bit on what you said about “For things to be cleaned up correctly, we have to ensure that things don’t actually get destoryed, but rather added to the visible DOM just before unload (as the pattern describes would imply)”?

One thing I would love to see is a resource which explicitly describes the leak patterns, and proper ways to deal with them.

Comment by Frank — September 19, 2007

I´m so happy I saved my time throwing my own related code out of my lib… I really don´t understand this behaviour from Microsoft. We really need cross-browser JS engine plugins with auto-update and a valid open source reference implementation… :-(

Comment by Frank Thuerigen — September 19, 2007

We also do some pretty awful backflips to work around this problem, though they tend to remain buried in the low-level GWT libraries. The hardest problem to deal with, in my experience, is avoiding leaks *while the app is running*. That is, if I create a widget, use it, then throw it away while the app is running, it needs to get cleaned up.

Otherwise, you’ll end up blowing enormous amounts of memory in a long-running app.

This article’s very GWT-specific, but will give you some of the flavor of how we approach the problem: http://code.google.com/p/google-web-toolkit/wiki/DomEventsAndMemoryLeaks

Comment by Joel Webber — September 20, 2007

Oh, come on, http://browsehappy.com/why/

Be happy, now ;)

Comment by Nikita Kapustin — September 23, 2007

Has anyone faced an issue of leaks when using prototype.js and dojo.js in the same page ?
For this leaks like anything in IE 6 & 7 :( !!!

Comment by Soney — January 29, 2008

i know this post is old, but just in case anyone want to reference the article mentioned in the post, it’s been relocated here: http://blog.j15r.com/2007/09/ies-memory-leak-fix-greatly-exaggerated.html

Comment by tomh — October 16, 2009

Leave a comment

You must be logged in to post a comment.