JScript Memory Leaks

Douglas Crockford
www.crockford.com

When a system does not correctly manage its memory allocations, it is said to leak memory. A memory leak is a bug. Symptoms can include reduced performance and failure.

Microsoft's Internet Explorer contains a number of leaks, the worst of which is an interaction with JScript. When a DOM object contains a reference to a JavaScript object (such an event handling function), and when that JavaScript object contains a reference to that DOM object, then a cyclic structure is formed. This is not in itself a problem. At such time as there are no other references to the DOM object and the event handler, then the garbage collector (an automatic memory resource manager) will reclaim them both, allowing their space to be reallocated. The JavaScript garbage collector understands about cycles and is not confused by them. Unfortunately, IE's DOM is not managed by JScript. It has its own memory manager that does not understand about cycles and so gets very confused. As a result, when cycles occur, memory reclamation does not occur. The memory that is not reclaimed is said to have leaked. Over time, this can result in memory starvation. In a memory space full of used cells, the browser starves to death.

We can demonstrate this. In the first program, queuetest1, we will create 10000 DOM elements (spans), and at the same time, delete all but the 10 most recent. When you run it with the Windows Task Manager's Performance display, you will observe that PF (Page File) Usage remains fairly constant. Changes on PF Usage can be an indicator of memory allocation inefficiency.

Next, run the second program, queuetest2. It does the same thing as queuetest1, except that it adds a click handler to each element. On Mozilla and Opera, the PF Usage is about the same, but on IE we see a steady increase as memory leaks away at a rate of about a megabyte per second. Often this leakage is unnoticable. But as Ajax techniques become more popular, with pages staying in place longer, being subjected to many changes, failure becomes common.

Since IE is unable to do its job and reclaim the cycles, it falls on us to do it. If we explicitly break the cycles, then IE will be able to reclaim the memory. According to Microsoft, closures are the cause of memory leaks. This is of course deeply wrong, but it leads to Microsoft giving very bad advice to programmers on how to cope with Microsoft's bugs. It turns out that it is easy to break the cycles on the DOM side. It is virtually impossible to break them on the JScript side.

When we are done with an element, we must null out all of its event handlers to break the cycles. All we have to do is assign null to each event handler's property. This can be done very specifically, or we can make a generic purge function.

The purge function takes a reference to a DOM element as an argument. It loops through the element's attributes. If it finds any functions, it nulls them out. This breaks the cycle, allowing memory to be reclaimed. It will also look at all of the element's descendent elements, and clear out all of their cycles as well. The purge function is harmless on Mozilla and Opera. It is essential on IE. The purge function should be called before removing any element, either by the removeChild method, or by setting the innerHTML property.

function purge(d) {
    var a = d.attributes, i, l, n;
    if (a) {
        l = a.length;
        for (i = 0; i < l; i += 1) {
            n = a[i].name;
            if (typeof d[n] === 'function') {
                d[n] = null;
            }
        }
    }
    a = d.childNodes;
    if (a) {
        l = a.length;
        for (i = 0; i < l; i += 1) {
            purge(d.childNodes[i]);
        }
    }
}

So finally we run the third program, queuetest3. In it, the purge function is called just before deleting DOM elements.

Note that handlers that were added with attachEvent() will not be found and will continue to leak.

Update: Microsoft has released a fix to this problem: 929874. If you can be confident that all of your users have accepted the patch, then it is no longer necessary to purge. Unfortunately, it is not possible to determine that, so purging will probably remain necessary for the rest of IE6's product life.

This is the nature of the web. Fixing bugs doesn't make the bugs go away.

Update: Ok, IE7 didn't fix it. Maybe IE8 will fix it.