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!

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.

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.

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… :-(

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.