Cycle collector landed

January 5th, 2007

The previous attempt at landing the XPCOM cycle collector failed due to some unacceptable performance regressions. Yesterday, after tidying up a few of the more obvious offenders, we appear to have accomplished a landing that only hurts Tp2 by 5-15%, depending on platform and noise. I know this sounds like a big number and I will endeavor to make it smaller, but it was a big change that causes a lot of new pointer operations and a big new cost center in the GC itself. So getting it that low is mildly satisfying. Thanks to jst, vlad, brendan and others for all the hand-holding.

I’ll repeat my previous qualifications of this work, though. Despite the claims in the literature, no real GC system is free — they all cost time for the scanning and space for the transient garbage — and this is possibly one of the least satisfying GC systems because you have to manually add every class you want to participate in it. In the short term, you can expect: some performance loss, some heap increase, and a good number of leak-analysis tools to complain that memory is being leaked due to assumptions they make about the lifecycle of objects.

It is also reasonably likely that the collector will trigger new crashes; gecko still carries a lot of assumptions about pointer lifetimes, and it’s easy to accidentally write a traversal method that violates one. As we bring more classes into the collection regime and make more pointers strong, such opportunities should decrease.

In coming weeks I’ll try to work through each reported problem like this that comes up. Please let me know if you have a specific result that’s worrying you, and make sure to CC me on any bug that has a cycle collector frame in its stack.

6 Responses to “Cycle collector landed”

  1. Steve England Says:

    You say “In the short term, you can expect: some performance loss, some heap increase, and a good number of leak-analysis tools to complain that memory is being leaked”. What can we expect in the long term? Performance gain, memory usage decrease, less leakage or what?

  2. Albert Says:

    As the cycle collector can detect garbage cycles (and remove them) memory usage should be more constant over usage time (memory that was previously not released will be now). I guess there’s no real performance gain, but that’s not the issue. What’s really important is that programmers don’t have to think about the previous (hard to understand) behavior anymore and can use cleaner code… but I guess Graydon could sum up more advantages ;)

  3. Tommy Says:

    Interesting question indeed… will this fix (at least some of) the famous Firefox memory usage thing? Ever since Gecko 1.9, my Firefox uses too much memory too… if this cycle collector won’t fix those problems: what *does* it fix? :)

    Keep up the good work, by the way!

  4. graydon Says:

    It will not, in the short term, reduce the amount of memory Firefox uses.

    It may be useful to mentally categorize the memory Firefox uses in the following senses: normal memory usage required by any sensible browser doing what firefox is doing, pathological memory usage caused by a coding error that retains too much reachable memory, and pathological memory usage caused by cyclical garbage — unreachable memory that keeps itself alive due to internal references. This patch is infrastructure work that might, some day, help with the last category on that list.

    Gecko currently copes with ownership cycles in an ad-hoc fashion. Some code attempts to manually disconnect cycles at opportune moments. Other code attempts to avoid setting up cycles by using raw pointers and trying to ensure that no possible code paths result in those pointers being reachable when their referent is not. Other code uses first-class weak pointers. It’s a mixed bag, and not always easy to get right: sometimes an edge should be strong in some contexts and weak in others. Often the cycle is so complicated we don’t even see it.

    This patch introduces a new, more uniform strategy to use for ownership cycles: make all the classes involved into cycle-collection participants, and make all the edges between them strong pointers (nsCOMPtr).

    This has some benefits and some costs.

    The benefits are that code becomes simpler and easier to maintain — all edges should just turn into owning edges — and it becomes less likely that any given change to the code will introduce a cycle or break an existing, implicit cycle-management assumption. Longer term, some cycles we didn’t even know we had may even solve themselves, if enough classes are made into cycle-collection participants.

    The costs are general disruption, delicate interaction with all the existing ad-hoc cycle-management constructs, and the runtime performance and memory hits.

    Note that this is only one memory-management scheme. There are others on the table. In the coming year I’ll be building a variant of Firefox that attempts to use Tamarin’s conservative garbage collector system-wide. That is a more disruptive change, however. The XPCOM cycle collector, believe it or not, is the “least disruptive” of the possible new memory-management schemes we’ve looked at.

  5. The Burning Edge » Blog Archive » 2007-01-11 Trunk builds Says:

    [...] Fixed: 333078 – XPCOM Cycle Collector. This hurts speed by 3-5% in the short term; see comments 82-85 and Graydon’s blog post. [...]

  6. Jason’s blog » Blog Archive » Part 1: The Monkey of Action Says:

    [...] front. Mozilla uses reference counting pretty heavily; it even includes a (relatively new) cycle collector that detects refcount cycles, even cycles that pass from C++ to JavaScript and back again. Tamarin [...]

Leave a Reply

You must be logged in to post a comment.