Tuesday, 14 November 2006

Garbage Collection

Thought I'd post up a bit I wrote at work discussing differences in memory handling and garbage collection in different browsers.

Microsoft's implementation of ECMAScript is actually called JScript (not JavaScript), and it's behaviour with regards to garbage collection differs from the original implementation of JavaScript in SpiderMonkey (SpiderMonkey is the name for the first JavaScript engine written by Netscape, Firefox is based on this engine). It's worth noting that the JScript/JavaScript engine does not itself provide a host environment for the DOM - they are two separate structures that exist together, but can logically exist apart.

The main difference
IE uses non-generational mark and sweep garbage collection versus SpiderMonkey's generational mark and sweep garbage collection. The "mark and sweep" bit means that each object (either JScript or JavaScript) has an attribute that is set to 1 if it is to be collected and 0 if it is not. As the generational/non-generational bit of the name implies, what it means is that SpiderMonkey will find older objects first and clean them out (generational), whereas IE will do this fairly indiscrimately and just find JScript objects in memory and check to see whether to garbage collect them (non-generational). Simply put SpiderMonkey will push the objects to be collected to the bottom of the memory heap (http://en.wikipedia.org/wiki/Heap_(programming)) and then knows to grab the bottom of the pile to free memory, whereas JScript will throw objects (relatively) randomly onto the heap and then pick through all of them individually checking to see if that object needs collecting. As you can imagine there's an impressive performance lean towards generational garbage collection.

Because of the relationship between the DOM and the JScript/JavaScript engine, stacking objects in memory becomes very important. As you can imagine, keeping less objects in memory now has real performace implication in IE - especially circular references between the engine and the DOM such as an array of nodes - an example of this problem would be memory leaking through event handlers in the DOM (http://www.jibbering.com/faq/faq_notes/closures.html#clMem) - in fact this problem surfaces with any sort of large numbers of data types/objects held in memory at one time. It also should promote forced memory handling when resources can become free, rather than simply waiting for automatic garbage collection to be initiated (statements such as "myArray = myString = myNumber = null") to make sure the object has the least memory allocated to it after use and the automatic garbage collection then becomes much quicker.

Links to more info
Garbage collection: Wikipedia Garbage Collection
SpiderMonkey: Wikipedia SpiderMonkey
Garbage collection models: North Eastern University