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.