

JavaScript memory leak patterns - BudVVeezer
http://www.ibm.com/developerworks/web/library/wa-memleak/

======
cscotta
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/>

------
cbetz
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?

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

~~~
natrius
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.

~~~
BudVVeezer
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!).

------
Plugawy
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...](http://www.sitepoint.com/blogs/2008/07/23/javascript-event-
delegation-is-easier-than-you-think/)

