Comments on: Is “finally” the answer to all IE6 memory leak issues?

By: Naruto

Naruto — Thu, 09 Oct 2008 21:29:17 +0000

Thank for the info

By: uize

uize — Wed, 11 Jun 2008 15:48:51 +0000

@Jordan
That’s pretty cute.

By: Fredrik

Fredrik — Wed, 11 Jun 2008 07:34:32 +0000

@Geompse:
AFAIU your code example doesn’t leak, thus you don’t need any of the tricks above. It’s only when you created a closure that also “consumes” a DOM-element you need to do nulling.

By: Geompse

Geompse — Tue, 10 Jun 2008 21:04:25 +0000

huh, question :

function x()
{
var a = document.createElement(‘div’);
return a;
}
function y()
{
var b = x();
return b;
}
document.body.appendChild(y());

as I understand, i shall put “try{return a;} finally{a=null;}” in function x. but shall i put “try{return b;} finally{b=null;}” in function y ?

By: Jordan

Jordan — Tue, 10 Jun 2008 05:25:06 +0000

We use something like this in our company:
function create() { var a = document.createElement("div"); a.onclick = function() { //... }; return (a = [a]).pop(); }

By: uize

uize — Mon, 09 Jun 2008 23:07:42 +0000

It’s a busy day at Zazzle (Monday’s are meeting days), but I will do some more digging and hopefully report something interesting.

By: uize

uize — Mon, 09 Jun 2008 23:06:33 +0000

@jgw
Drip was used to test leaking in IE6 – not IE7. Also the hash table is not a global variable, but stored as a property of a global object. That particular pattern, at the time, resulted in Drip reporting no leaked DOM elements, and the memory usage of IE6 not creeping up uncontrollably on each subsequent page refresh.

By: Fredrik

Fredrik — Mon, 09 Jun 2008 22:42:26 +0000

Isn’t a local factory just as good?
function createDOMThingy()
{
function createAndHookup(onClick)
{
var elem = document.createElement(‘div’);
elem.onclick = onClick;
return elem;
}
return createAndHookUp(function(){ alert(‘click!’); });
}

By: cromwellian

cromwellian — Mon, 09 Jun 2008 22:08:32 +0000

It’s not just expandos tho. If you use .onXXX, or attachEvent, the same leak will occur. It’s any reachable reference from the DOM node into the JS which causes the issue for removed/replaced elements.

By: HedgerWang

HedgerWang — Mon, 09 Jun 2008 21:34:49 +0000

Attaching “any” JS objects to a DOM element would introduce memory leak, and that’s why add expando to an element is a bad idea.

After M$ had released several fixes to fix the IE memory leaks bug, it turns out that IE does remove all JS objects attached to DOM elements before the unload event is triggered as long as those DOM elements remain valid in the document tree.

For element removed or replaced (eg.document.body.innerHTML = “”) from the document tree before the unload event, IE won’t be able to recycle the memory from the JS objects attached to those elements.

By: jgw

jgw — Mon, 09 Jun 2008 21:00:05 +0000

The problem with that approach is that you now have the following reference chain: { handlerFunction -> hashTable -> trueHandlerFunction -> element }. If the hashTable is simply a global, then the handlerFunction still has an implicit reference to it (by virtue of the fact that everyone has an implicit reference to the global scope). This is generally not a big deal with a simple handler function, but if that handler has a reference to a more complex “peer” javascript object (very common in UI frameworks), then the leak can be much larger.

It is possible that Drip is showing that you have no leaks, because IE (7, at least) cleans up event handlers it can find in the DOM on unload. Drip can only check for leaks present *after* the page is fully done unloading (I wrote Drip a few years ago, but haven’t really maintained it much since).

By: uize

uize — Mon, 09 Jun 2008 20:33:36 +0000

The trick is to break the *reference* chain. If the event handler that is directly assigned to the DOM node has a string variable (closure scoped) that contains a key which it can use to look up a true handler in a hash table, then the handler does *not* have a reference to the true handler function. Therefore, the DOM node does not have a reference to the true handler function. In all likelihood the true handler function hangs on to a reference to the DOM node, but this is OK because there is now no circular reference taking place.

It was a long time ago that I solved this problem and made a test to verify that it worked. I was using a little utlility called Drip at the time that indicated that with the CRIS in place, there were no leaked DOM nodes across page refreshes. Needless to say, it was a relief to solve this problem in an elegant way. Prior to this, UIZE had a workaround for IE6 where cleanup would happen on page unload (the traditional way). I remember that the key thing was to keep the direct handler function definition outside of a scope which held a closure reference to the hash table.

By: jgw

jgw — Mon, 09 Jun 2008 20:05:55 +0000

Cromwellian’s comments (hi, Ray!) are pretty much right on the money. No amount of indirection through hash tables or any other mechanism will change the fact that you’ve got a circular reference. Think about it this way: If I’ve got a Javascript object that references a DOM element, and it’s possible to reach that object *in any way* from the DOM element (including its event handlers), then you’ve got an uncollectible circular reference in IE. This can only be fixed by breaking the circular reference at some point before the page unloads, and once you do so, whatever was depending on that reference (e.g. being able to handle events correctly) will no longer work.

The trick described in this article works for the sole reason that the only circular reference involved is { functionScope -> element -> eventHandler -> closure -> functionScope }. The finally block just clears out the { functionScope -> element } part of the reference after the return value is computed. This in no way solves the general problem described above. The only general solution is to break circular references when an element is “disposed” (i.e. whenever it is no longer needed by the app, and before the page unloads).

By: Nosredna

Nosredna — Mon, 09 Jun 2008 19:33:51 +0000

>>We need to make sure that the people USING IE6 know that it is garbage.

They often do know it. Many of them work at places where IT has mandated IE6. These are often oppressive places to work, and telling the user that the browser sucks is just adding to the punishment they already endure.

You have to decide if it’s worth dealing with IE6 or not. A local newspaper’s site stopped working on IE6 recently. The programmers get the complain calls forwarded to them (something like 20% of the users had been on IE6 still), and they have to explain on the phone that IE6 is no longer supported. That seems like a great way to alienate your customers to me.

I’d LOVE it if IE6 went away. It uss up probably half my browser-specific time. It’ll be a big win when I can drop it.

By: cromwellian

cromwellian — Mon, 09 Jun 2008 19:08:42 +0000

I’ve talked to people who have implemented CRIS style stuff before, it’s a fairly obvious workaround, but AFAIK, it doesn’t work perfectly either. The GC shouldn’t care whether references are direct or indirect with respect to cycles. If an element has a reference to another JS object, which references another, which eventually references the original element, you have a cycle. There’s nothing special about A->B->A vs A->B->C->A. It shouldn’t matter if C is a direct reference, or a hash table with a bunch of references, one of whom happens to be A.

AFAIK, no framework that doesn’t track unattached DOM elements and clean them up on page load (or unattachment) can avoid leaking.

By: uize

uize — Mon, 09 Jun 2008 19:04:32 +0000

@Bryan,
So, what you’re saying is that IE6 is in need of some garbage collection ;-)

By: polterguy

polterguy — Mon, 09 Jun 2008 18:58:07 +0000

Here’s another solution that will completely eliminate the entire stack of problems;
http://ajaxwidgets.com/Blogs/thomas/the_entire_web_is__best_viewed.bb
;)

By: Bryan

Bryan — Mon, 09 Jun 2008 18:56:40 +0000

Why bother fixing IE6 issues? Yes, I know it is still being used heavily, but the issue remains. IE6 is garbage and we all know it – thats why we “fix” it all the time with CSS and JS hacks.

We need to make sure that the people USING IE6 know that it is garbage. From their point of view – “if it ain’t broke, dont fix it” so they may never upgrade.

While this is an interesting hack, the focus shouldn’t be on saving IE6 it should be on eliminating it and making sure that the end users know that they have better options.

By: uize

uize — Mon, 09 Jun 2008 18:49:50 +0000

One way to avoid circular reference related DOM memory leaks in IE6 is to institute a CRIS (Circular Reference Isolation System). Your framework should provide methods for abstracting the assignment and removal of event handlers on DOM nodes. With such an abstraction, you can institute a CRIS to enforce a breakage in the circular reference between referenced DOM nodes and lambda closures that would implicitly be linked by reference to the DOM nodes.

Basically, the DOM node has a reference to the closure function (the event handler). The closure function has a reference to the state of its enclosing scope, which has a variable that is a reference to the DOM node. IE6 doesn’t identify and resolve circular references that span the JS/DOM divide.

A CRIS works by assigning an intermediary “joiner” function as the actual event handler of the DOM node, and ensures that this intermediary function does not have a direct reference to the handler function being assigned by the application. Instead, the real handler is looked up from a hash table, using a key that is stored through closure with intermediary. This effectively breaks the direct reference chain, so IE6 doesn’t hang on to DOM nodes. To the application developer, everything behaves the way they would like. They can assigned closure functions as event handlers without worrying about circular references.

PLUG (of course, you knew it was coming): The UIZE JavaScript Framework employs a CRIS in its Uize.Node package, so that the event handler methods ensure no circular references that would lead to DOM memory leaks in IE6.

By: Spocke

Spocke — Mon, 09 Jun 2008 18:33:50 +0000

I played around with this finally approach tested it in sIEve and it does really seem to solve the circular reference memory leak. Very strange that it works. However it doesn’t directly solve the circular reference problem that the attachEvent method in IE introduces so I wrote a small proof of concept class that fakes this behavior.

I verified that it doesn’t leak in IE using sIEve and it works in all browsers:
http://blog.moxiecode.com/2008/06/09/leak-free-event-class-that-doesnt-use-the-unload-event/