What’s new in Firefox 6 from the GC side?

Firefox 7 comes with awesome memory fixes but there are also major Garbage Collection (GC) improvements in Firefox 6. Firefox has a stop-the-world mark-and-sweep garbage collector with conservative stack scanning. In prior work we reduced the workload of an average GC to the compartment (or tab) that allocates most memory and therefore is a good target to reclaim most memory.

For huge workloads within a single tab we still end up with long GC pauses because every single reachable object has to be marked and every unreachable object has to be finalized. Finalization in JavaScript has a different meaning than in Java where the language supports an explicit finalization function. JavaScript doesn’t support such behavior but we call a VM internal finalization function on every reclaimed object that frees dynamically allocated memory for example.

Depending on the workload we can get GC pauses up to  200 msec or even more on low-end laptops. If most objects are reachable we have high marking cost and if most objects are unreachable we spend most time in sweeping. We talked about an improvement of the sweeping phase for a long time and a few months ago I landed a patch where most finalization is moved from the main thread to a background thread. We can’t do all finalization on the background thread because the browser uses external finalizes that rely on the finalization during the GC event. Our measurements show that we usually finalize more than 95% of all objects on the background thread.

The main JavaScript thread can still allocate new objects during the background thread is running. We simply allocate new memory if the finalization is not done yet. This gives us a 300 points or 10% improvement on the V8 benchmark scores and regular users will see a GC pause time reduction between 20% and 80%.

Bill McCloskey is also working on a generational and incremental GC model that will show further improvements.