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?
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!
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?
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.
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?
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.
If it helps Firefox competing with Chrome, then that’s very good news.
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.
I’m glad my beloved Firefox is always improving. Thanks to all developers for more one milestone.