JavaScript closure and IE memory leak

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 webpage 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.

The fact is that IE has separate garbage collecting mechanisms for COM interfaces and JavaScript objects and is unable to resovle 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 reliefing and reasonable to expect that IE will relaim 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 cirular 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 demostrative purpose only and lacks of optimization.
//Do not use it in productive enviromnent!
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.

Advertisements
This entry was posted in JavaScript. Bookmark the permalink.

3 Responses to JavaScript closure and IE memory leak

  1. Unknown says:

    wow gold!All wow gold US Server 24.99$/1000G on sell! Cheap wow gold,wow gold,wow gold,Buy Cheapest/Safe/Fast WoW US EU wow gold Power leveling wow gold from the time you wWorld of Warcraft gold ordered!

    wow power leveling wow power leveling power leveling wow power leveling wow powerleveling wow power levelingcheap wow power leveling wow power leveling buy wow power leveling wow power leveling buy power leveling wow power leveling cheap power leveling wow power leveling wow power leveling wow power leveling wow powerleveling wow power leveling power leveling wow power leveling wow powerleveling wow power leveling buy rolex cheap rolex wow gold wow gold wow gold wow gold -210090139423573

  2. Unknown says:

    Hi,Do you have used LCDs, used flat screens and secondhand LCDs? Please go here:www.sstar-hk.com(Southern Stars).We are constantly buying re-usable LCD panels and working for LCD recycling.The re-usable panels go through strictly designed process of categorizing, checking, testing, repairing and refurbishing before they are re-used to make remanufactured LCD displays and TV sets.Due to our recent breakthrough in testing and repairing technology of LCD, we can improve the value for your LCD panels.
    Contact Us
    E-mail:sstar@netvigator.com
    website:www.sstar-hk.com

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s