Generational GC has landed

Big news: late last week, generational garbage collection landed. It was backed out at first due to some test failures, but then re-landed and appears to have stuck.

This helps with performance. There are certain workloads where generational GC makes the code run much faster, and Firefox hasn’t been able to keep up with Chrome on these. For example, it has made Firefox slightly faster on the Octane benchmark, and there is apparently quite a bit of headroom for additional improvements.

Interestingly, its effect on memory usage has been small. I was hoping that the early filtering of many short-lived objects would make the tenured heap grow more slowly and thus reduce memory usage, but the addition of other structures (such as the nursery and store buffers) appears to have balanced that out.

The changes to the graphs at AWSY have been all within the noise, with the exception of the “Fresh start” and “Fresh start [+30s]” measurements in the “explicit” graph, both of which ticked up slightly. This isn’t cause for concern, however, because the corresponding “resident” graph hasn’t increased accordingly, and “resident” is the real metric of interest.

“Compacting Generational GC” is the #1 item on the current MemShrink “Big Ticket Items” list. Hopefully the “compacting” part of that, which still remains to be done, will produce some sizeable memory wins.

11 Responses to Generational GC has landed

  1. So it is in Nightly (31), assuming nothing bad happens, it will ship in v31?

    How long should we expect Compacting GC? Are talking about another year of work or a few months time?

    • Nicholas Nethercote

      It’s scheduled to ship in FF31, yes.

      I honestly don’t know how long compacting GC will take. Anywhere from a few months to a year sounds plausible!

  2. So then will the biggest wins from the GGC be reducing jank, speeding JS in some places, or merely setting us up for the compactor?

    • Nicholas Nethercote

      It’ll definitely speed up JS in some places. It might reduce jank by reducing the number of full collections needed, or making them less frequent.

      Exact rooting was the big prerequisite step for generational GC; it set things up so that GC things such as objects could be moved. And compacting GC also needs to move GC things, so in one way generational GC has set up things for compacting GC.

  3. Nic,

    This is great news! How would you characterize progress thus far towards crossing out the 5-items you called out in the Big Ticket Items list on Memshrink’s 2nd birthday? Specifically, now that Nuwa has landed, what are the big ticket B2G items?

    Thanks,
    Manoj

  4. and “resident” is the real metric of interest.

    I can understand the focus of the dev-team on resident, but the operating system (namely Windows) doesn’t care about resident but vsize. When vsize grows close to 4GiB, Firefox crashes, regardless of the size of resident.

    Are there plans to tackle the growth of vsize and vsize-max-contiguous?

    I’ve seen there’s a test on AWSY to see the memory-consumption after closing all test-tabs, and the size of used memory always falls back to almost the same value as before the start of the test.

    When I do the same with my normal browsing setup, i.e. closing all tabs and then wait a few minutes, vsize only shrinks marginally by a few percent while resident shrinks considerably.

    • Indeed, running out of virtual address space is a big problem on win32. Benjamin Smedberg and others have been looking into the problems there. It seems like there are a lot of possible issues there, like particular graphics drivers leaking address space, that may not be easy to fix.

      Hopefully, generational GC should help a bit with reducing fragmentation of JS memory over the duration of a long session, by reducing the amount of short lived things allocated in the same arena as long lived things, but I don’t think anybody has measured if that is actually the case.

  5. If it helps Firefox competing with Chrome, then that’s very good news.
    I wrote an article in French about it on http://mozillazine-fr.org/progres-des-performances-de-javascript-dans-firefox-nightly/
    Is it supposed to show in the graph on http://arewefastyet.com/ ?

    • If you look at the individual test breakdown for AWFY some are significantly faster and a few significantly slower; but the aggregate scores for the test suites are roughly equal. There used to be a large penalty for GGC that’s gradually gone away. I suspect that, along with stability, that performance parity achievement is a big part of why GGC was finally turned on by default in FF31.

  6. Arpad Borsos

    Awesome news! Thanks for all the hard work of the people involved. Looking forward to the compacting collector and some more memory savings :-)

  7. I’m glad my beloved Firefox is always improving. Thanks to all developers for more one milestone.