JavaScript memory leak patterns | Hacker News Reader

JavaScript memory leak patterns

ibm.com

32 pointsBudVVeezer7 comments

This article is a good description of circular references and memory leaks in JS, a pattern which is especially common in IE6 and one which my coworkers have spent a surprising amount of time combatting. Memory leaks border on a special kind of hypochondria, but once you can prove they exist, they're a bear to track down.

The biggest surprise in this article, however, was in the bio:

_"He has worked as a part of the OS/2 IBM Web Browser Support Team for the past three years."_

The OS/2 Web Browser was Mozilla-based, with open development happening in the free WarpZilla project. Apparently WarpZilla, a port of Firefox to OS/2, is still going strong as of version 3.5.4 (with prereleases of Fx3.6 and Fx3.7 still available): http://www.mozilla.org/ports/os2/

Please correct me if I am wrong, but shouldn't developers only worry about the issues mentioned in the article on older browsers? (I'm thinking IE6 and earlier).

Introducing a leak via circular references would be considered a bug in most modern JS engines, right?

A related question: Can someone recommend a good plugin/extension for monitoring the size of a page's javascript memory usage over time?

Chrome's Web Inspector lets you take heap snapshots at different times. It won't give you a graph of memory usage, but it will let you monitor it at different times

I think developers should always try to avoid poor programming practices instead of relying on implementation details of the browser.

Poor programming practices? The code that creates circular references is clearer than the example workarounds. Sacrificing clarity to avoid a problem that doesn't occur in supported browsers doesn't make much sense.

Failing to call "delete" on a pointer you "new"'ed in C++ is also clearer, and just as incorrect. The ECMAScript spec makes no mention of how memory will be managed for the user. Right or wrong in terms of clarity, it's still a poor practice to assume the browser will behave in a particular way that's not covered by the specification (regardless of how sensible that behavior might be!).

One more way of avoiding memory leaks is event delegation - here's quite good article about it: http://www.sitepoint.com/blogs/2008/07/23/javascript-event-d...

Reply on news.ycombinator.com