JavaScript:GC

The purpose of this page is to organize future GC work. Some of these changes are described in more detail in JavaScript:GenerationalGC. However, this page is intended to be about GC in general. A lot of this information is already in Bugzilla. This page is meant to be a summary of what everyone is working on and what our priorities are.

Background Finalization (bug 627200). Takes care of sweeping and finalization of the most common size classes in a separate thread.

• Owner: Gregor
• Status: Complete.

Parallel Marking (bug 638660). Uses multiple threads to for marking.

• Owner: Gregor
• Status: Up for review.

GC Test Pilot Study (bug 622638). This will allow us to find out how bad the GC is performing in real-world situations. As we make improvements, we should be able to measure their effect.

• Owner: Chris
• Status: Up for review.

Write Barriers (bug 641027). We need this for both incremental and generational GC. For incremental GC, when doing the assignment x.f := y, we need to mark the old value of x.f. For generational GC, we need to save &x.f somewhere if y belongs to the nursery.

• Owner: Bill
• Status: It's now possible to run the interpreter and method JIT in the shell. Code to verify that no unbarriered writes occur seems to work. Work on the trace JIT is ongoing. Eventually, XPConnect and NPAPI will need to be fixed in order to get a browser started.

Eliminate Finalizers (bug 648320). In preparation for generational GC, we want to make sure that we never touch objects that are garbage. This should significantly reduce cache traffic. Background finalization helps here, but it would be better just to get rid of the finalizers. To do this, we need to create new size classes to hold things like object slots. The main difficulty will be dealing with large objects. However, done properly, I think we can pretty much eliminate the cost of finalization.

• Status: Needs an owner.
• Prerequisites: None

Switch to Bump-Pointer Allocation (bugs 650095 and 601075). In order to completely eliminate finalization overhead (and the resulting cache traffic), we need to avoid building up the freelist since this also forces us to write to garbage objects. Some form of bump-pointer allocation is the solution. Igor's patch in bug 601075 uses bump-pointer allocation in arenas that have no allocated objects. This gets us part of the way there. It's not clear how important it is to go all the way to full bump-pointer allocation. Complicating the matter, switching to generational GC will completely change the trade-offs.

• Owner: Igor
• Status: Igor has a patch in bug 601075.
• Prerequisites: None

Incremental GC Scheduling (bug 641025). Once write barriers are in place, we just need to decide when to schedule an increment of GC and how long the increment should be. This will mostly be a matter of tuning to make sure we don't regress any benchmarks.

• Prerequisites: Write barriers.

Moving Collection (bug 650161). In preparation for generational collection, we need to be able to move objects without crashing. The purpose of this bug is to do as much moving as possible, while mprotecting the old objects so that they can never be touched again. This way, if we fail to update any pointers, we will find out quickly.

• Owner: Chris
• Status: Shell starts up without crashing when JITs are disabled. We still need to take care of the JITs as well as everything outside JS-land.
• Prerequisites: None

Generational GC (bug 619558). See JavaScript:GenerationalGC for more information. We'll probably start with the simplest possible generational collector.

• Prerequisites: Write barriers, moving collection (although fixing the finalization issues should be a big boost).