XPCOMGC

XPCOMGC is the Mozilla 2 project to convert the XPCOM object model from reference counting to use garbage collection.

General Info

Tracking is bug XPCOMGC.

TODO: collect/format information from the newsgroup discussion.

Rationale

We need to be able to free cycles of XPCOM objects. Mozilla 1.9 introduced a cycle collector to do just that. We've already removed hacks to avoid creating reference cycles, so we're now dependent on this.

The cycle collector should be replaced with a real GC. The cycle collector is complex. It requires cooperation from the objects that might appear in cycles. It interacts with the JS garbage collector in a way that verges on black magic.

A single true GC covering both XPCOM objects and JS is a much more direct approach. It will not make it much easier to debug memory leaks or crashes, but the GC itself will be faster and easier to maintain, and client code will be simpler.

The big advantage of the cycle collector was a software engineering win: it did not touch any of the reference-counting, the addrefs and releases in XPCOM client code. Now that we have better static analysis and rewriting tools, we can consider true GC.

We can't use a Java-style copying GC. The fastest GCs are generational copying GCs. But a fully copying GC is unsuitable for C++. When GC happens, if any pointers are in registers or stack locations that the GC doesn't know about, the objects they point to must not be moved. The only solutions are:

• Get information from the compiler about stack locations. (This is what Java does; the information is supplied by the JIT. It's basically impossible to do this for C++.)

• Conservatively scan the stack for pointers to GC-managed memory and don't move those objects.

• Don't use a GC that moves stuff around in memory. (This seems like the best approach.)

The amazing speed of a copying, generational GC depends on its being able to move all objects out of a generation. Then that whole region of memory is available for new allocations, which leads to an incredibly fast allocation routine—a few instructions in some cases. This kind of design is not viable for Mozilla, given our dependence on C++.

The GC should have conservative stack scanning. This makes life a lot easier for developers.

The GC has to support existing uses of threads in Mozilla. This pushes us toward using the JS request model.

Tasks

• Add the request model threadsafety to MMgc bug 395962
• Give MMgc the ability to recognize "inner" pointers to objects as typically used by C++ multiple inheritance bug 388070
• Make the world depend on a common MMgc
• Rewrite XPCOM addref/release handling
  • Remove the cycle collector
  • Use textual search/replace to remove most calls to NS_ADDREF/NS_RELEASE
  • Use automatic finding to identify remaining references for manual cleanup
  • Make all COM objects inherit from GCObject
  • Rewrite nsCOMPtr+friends to be a lightweight wrapper for GC writebarriers
  • Make stack pointers raw pointers
  • Fix some COM-holding utility classes:
    • nsCOMArray
    • hashtables: nsInterfaceHashtable and nsInterfaceHashKey
  • Rewrite XPCOM weakrefs to be GCWeakRefs
    • And remove those that can be regular GC references
• Identify and deal with multi-threading, especially
  • Initialize and suspend requests around blocking activity
  • Analyze code for deadlock possibilities.
• Set up a static checker based on GCC to enforce common invariants

Building XPCOMGC

The XPCOMGC work is currently taking place in mercurial patch queues on top of the ActionMonkey repositories. Follow the instructions below to build:

~ $ builddir=/builds/xpcomgc
~ $ cd $builddir
/builds/xpcomgc $ hg clone http://hg.mozilla.org/actionmonkey/ src
/builds/xpcomgc $ cd src
/builds/xpcomgc/src $ hg clone http://hg.mozilla.org/users/bsmedberg_mozilla.com/xpcomgc-patches/ .hg/patches
/builds/xpcomgc/src $ head .hg/patches/series
# Currently based against actionmonkey revision AA112233
/builds/xpcomgc/src $ hg up AA112233
/builds/xpcomgc/src $ hg qpush -a
/builds/xpcomgc/src $ hg clone http://hg.mozilla.org/actionmonkey-tamarin js/tamarin
/builds/xpcomgc/src/js/tamarin $ cd js/tamarin
/builds/xpcomgc/src/js/tamarin $ hg clone http://hg.mozilla.org/users/bsmedberg_mozilla.com/xpcomgc-tamarin-patches .hg/patches
/builds/xpcomgc/src/js/tamarin $ head .hg/patches/series
# Currently based against actionmonkey-tamarin revision BB445566
/builds/xpcomgc/src/js/tamarin $ hg up BB445566
/builds/xpcomgc/src/js/tamarin $ cd $builddir/src
/builds/xpcomgc/src $ python client.py checkout --skip-mozilla --skip-tamarin
/builds/xpcomgc/src $ autoconf-2.13

This will get you to a state before automatic patching occurs. This tree should build correctly, if you pass WARNINGS_AS_ERRORS= on the make command line. You can generate and apply the automatic patches using the script:

/builds/xpcomgc/src/.hg/patches/generate-automatic-patches.sh

You will need the oink stack and pork-barrel installed, and may need to edit paths in that file to match your local system.