Tools for Detecting Memory Leaks

As many web devs know, it’s relatively easy to build a site which results in memory leaks when viewed in Internet Explorer. IE team members have written MSDN articles on leak patterns, and other sites have posted articles with varying tone, depending on the author’s frustration with the problem.

These memory leaks often occur as a result of circular references between Jscript objects and objects within IE’s DOM (document object model). Since the Jscript engine and IE have independent memory management schemes, each side can’t see the entire cycle of these circular references.

Internet Explorer 7 improved the situation by releasing all references to Jscript objects attached to the DOM tree when IE navigates away from that page. This allows the Jscript engine to then garbage collect those Jscript objects and recover that memory. We’ve also made the same changes in IE6 on Windows XP SP2 (shipped originally with the June Update). However, as some web developers have pointed out, those changes don’t solve the problem entirely. IE still leaves behind anything not attached to the tree when we tear down the markup. In addition, sites that users keep open for extended periods of time, such as Web-based mail, can still cause IE’s memory usage to continually grow if the site doesn’t take care to avoid the leak patterns.

So no, it’s not perfect, but we’re also continuing to invest in improvements for future versions of IE.

In the meantime, tools and best practices can help web developers find and remove leaks today.

Drip and sIEve (joint SourceFourge site) are two such tools. Many of you may already be familiar with them, but a little extra visibility never hurts. Both applications host Trident – IE’s rendering engine – and add detection of memory leak patterns. They let you track memory and DOM usage while using a site and then detect any leaks when you navigate away from that page. Drip is an open source project under the BSD license. Based on Drip, sIEve improves the usability in a few ways including non-modal dialogs and a real-time graph of DOM usage instead of memory usage. If you have questions/comments about the tools themselves, try the documentation, forum, or mailing list. And if you’re interested in taking a more active role in the project, contact Matthias Miller through the forum or mailing list.

Those tools will you help find the leaks, and here are a few articles that provide more information about removing them, or better yet, avoiding them in the first place: