In garbage-collected languages, such as JavaScript, you cannot have traditional memory leaks by forgetting to free memory: when all references to an object are dropped, the object is garbage-collected and the memory is freed.
However, JavaScript programs can leak memory by unintentionally retaining references to objects. For example the references can be pointers to objects stored in a data structure in a JavaScript library (e.g., Closure) instead of the application code. If an object is unintentionally retained, all objects it points to are kept alive as well. This will lead to superfluous memory consumption.
Example (using the Closure JavaScript library):
goog.Disposable is an interface for disposable objects. Before dropping the last reference to an object which is an instance of goog.Disposable (or its subclass), the user code is supposed to invoke the method dispose()on the object. This method can release resources, e.g., by disposing event listeners. However, a web application might forget to call dispose() before dropping all the references to an object.
Leak finder can detect such goog.Disposable objects which were not disposed, and print out useful information (such as the stack trace when the object was created) about them. It produces machine-readable output and can be used as a part of test automation.
In order to find leaks, Leak Finder relies on goog.Disposable monitoring mode. The mode gathers all created but not yet disposed instances of goog.Disposable (and its subclasses) into an array goog.Disposable.instances_. This array will keep the objects alive. However, if an object is only kept alive by this array and other Closure data structures, it is a leak, since the user code doesn't contain any pointers to the object, and it cannot call dispose() on it.
.png)
The Leak finder project page contains instructions for checking out the source code and using the tool.
By Marja Hölttä & Jochen Eisinger, Chrome team (Munich)
