Tuesday, September 18th, 2007
IE’s Memory Leak Fix Greatly Exaggerated
<p>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!








Hmmm,
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.
Stephen
Only loosers still use IE nowadays
Enjoy the web, there is plenty to do if your browser let you
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.
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.
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.
Told you so :p
http://weblogs.asp.net/bleroy/archive/2007/06/26/ie6-s-main-memory-leak-hot-fixed.aspx
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.
Wow, what happened to automatic garbage collection?
Alex,
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.
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.
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
Oh, come on, http://browsehappy.com/why/
Be happy, now ;)
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 :( !!!
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