JavaScript closure and IE memory leak

2007-06-27 08:26:49 UTC Update: Microsoft has fixed IE memory leaks problem. KB929874

2006-10-24 +8 Update: According to IE 7 vs IE 6, IE 7 seems to have solved the memory leaks. Cheers!

2006-09-24 +8 Update: See the follow up

"Betty: Your umbrella leaks, Professor Boffin!"    ---- Look, Listen and Learn

IE leaks memory like a sieve and my web page is getting slower and slo...ower. But memory usage keeps climbing...

I've tried everything including banging my head on the desk. It just doesn't change anything.

I read the following articles and fell asleep.

• IE: WHERE'S MY MEMORY?
• JavaScript Closures for Dummies
• JavaScript Closures
• Leak Free JavaScript Closures
• Memory Leakage in Internet Explorer - revisited
• addEvent() - My Solution
• Understanding and Solving Internet Explorer Leak Patterns
• Closures and IE Circular References
• Fabulous Adventures In Coding

The fact is that IE has separate garbage collecting mechanisms for COM interfaces and JavaScript objects and is unable to resolve circular references between DOM(or ActiveX or any kind of COM) objects and JavaScript objects. When objects form the two worlds have circular references between them, GC can not detect them and the memory cannot be reclaimed until IE exists. There are several patterns that cause circular references. Unfortunately, assigning nested functions as event handlers falls into this category. IE is rejecting the use of closure, one of the most powerful and flexible feature of JavaScript.

It is frustrating to know that experts at Microsoft like Eric Lippert suggest "Don't use closures unless you really need closure semantics. In most cases, non-nested functions are the right way to go." It sounds like that programmers are abusing closures, completely ignoring that IE has a big problem with closures. It would be relieving and reasonable to expect that IE will reclaim leaked memory after a page has been unloaded. But that's not the fact. And here I found some explanation: "...the application compatibility lab discovered that there were actually web pages that broke when those semantics were implemented.  (No, I don't know the details.) The IE team considers breaking existing web pages that used to work to be way, way worse than leaking a little memory here and there, so they've decided to take the hit and leak the memory in this case." I don't understand. Maintaining backward compatibility with rare web pages which even an scripting engine writer does not know much about at the cost of leaking memory possibly for all web pages? What kind of decision is it? They don't admit their own faults but instead suggest poor coding practices.

But we have to code for IE, however buggy it is. I've run the test from Mihai Bazon(see IE: WHERE'S MY MEMORY?).

function createEl(i) {     
	var span = document.createElement("span");     
	span.className = "muci";     
	span.innerHTML = " foobar #"+i+" ";     
	span.onclick = function() { 
		alert(this.innerHTML + "\n" + i); 
	};     
	document.body.appendChild(span); 
}  

function start() {     
	var T1 = (new Date()).getTime(); // DEBUG.PROFILE     
	for (var i = 0; i < 3000; ++i) createEl(i);     
	alert(((new Date()).getTime() - T1) / 1000); // DEBUG.PROFILE 
} 

The first request in IE took 1.797s, the tenth 8.063s. Memory usage kept growing. Firefox reports a typical value of 1.6xs with no memory leak. Prototype.js avoids IE memory leak by hooking window's unload event, unobserving all events and clearing its event handler cache. I replaced the line span.onclick = function() { alert(this.innerHTML + "\n" + i); };  with Event.observe(span, 'click', function() { alert(this.innerHTML + "\n" + i); }); and rerun the test. The good news is that the leaked memory in IE is reclaimed when the page unloads. The bad news is that each request takes approximately 17s in IE while Firefox only needs 2.1xs! The Prototype event system makes it possible to free memory when page unloads but is extremely slow and uses more memory in a single request.  The speed degradation is explainable: Event._observeAndCache saves extra references thus uses more memory and IE gets slow as it leaks memory. Event.observe does more things than a simple assignment thus is much slower. However, memory leak is under control... I admire Edward Dean's addEvent though it doesn't solve the memory leak problem with closures. (Dean insisted that his script does not leak memory in comments. Maybe he is not talking about the closure case). Leak Free JavaScript Closures solution can really prevent memory leak. The way it breaks circular reference inserting a new closure between the nested function and its closing scope. The fancy part is that when another level of closure is added, the inner closure can still access variables in its initial closing scope indirectly via scope chain without causing circular references between DOM objects and JavaScript objects. The way it breaks circular reference is create a new function which holds no references to the closing scope.

In the simplest case:

<script type="text/javascript">
//Holds references to functions
__funcs = []; 
//The code fragment is for demonstrative purpose only and lacks of optimization.
//Do not use it in productive environment!
Function.prototype.closure = function() {
	__funcs.push(this);
	return function () {
		return __funcs[__funcs.length - 1].apply(null, arguments);
	};
}; 
function setup() {
	var span = $('span1');
	span.bigProperty = new Array(1000).join('-_-');
	span.onclick = function() {
		alert(span.bigProperty.length);
	}.closure();
}
setup();
</script> 

This will not leak memory in IE. The nested function in setup() forms a closure so it's able access span. span.onclick does not refer to the nested function but a newly created function returned by the closure() method of the nested function. The newly created function invokes the nested function via global array __funcs and have no references to the scope of setup(). So there is no circular reference. You may argue that the newly created function is able to call the nested function, it must have some kind of reference to it while the nested function have reference to span via closure, so there will be a circular reference. However, ECMA 262 treat this as a keyword rather than an identifier, this keyword is resolved dependent on execution context in which it occurs, without reference to the scope chain (see Javascript Closures ). A global array is used to hold references to closures without modifying the internal [[scope]] object. This is a hack indeed. IE always needs hacks to amend its holes.