We added support for CGC in AWSY back in April [1], unfortunately the results were somewhat inconclusive. It looked like there was about a ~5MiB reduction in JS memory usage, but that ended up just falling into jemalloc’s heap-unused bucket (memory that is allocated, but currently unused). This may have improved since then and in general I would agree with Jon’s assertions that in “real life” scenarios we should see better results.
We also have an e10s branch of AWSY [2] that has been running internally for a few months.
That’s disappointing. If the reason the memory use after tabs closed and forced GC is so much higher than the startup memory numbers isn’t due to the heap filling up with mostly empty compartments; where is it going.
Can you say anything about how the e10s AWSY runs are going; or would I have to build and run my own copy to see what’s happening? With the initial e10s implementation only having a single content process (vs one per tab), I’d guess the only change would be a net upward shift due to the extra process overhead. I’d be happy to be proved wrong though; as slowly as the initial version is progressing I’m not holding my breath on more advanced versions coming out anytime soon.
3 replies on “Compacting GC”
Are compacting GC or e10s enabled on AWSY yet?
We added support for CGC in AWSY back in April [1], unfortunately the results were somewhat inconclusive. It looked like there was about a ~5MiB reduction in JS memory usage, but that ended up just falling into jemalloc’s heap-unused bucket (memory that is allocated, but currently unused). This may have improved since then and in general I would agree with Jon’s assertions that in “real life” scenarios we should see better results.
We also have an e10s branch of AWSY [2] that has been running internally for a few months.
[1] https://github.com/mozilla/areweslimyet/pull/98
[2] https://github.com/mozilla/areweslimyet/tree/e10s
That’s disappointing. If the reason the memory use after tabs closed and forced GC is so much higher than the startup memory numbers isn’t due to the heap filling up with mostly empty compartments; where is it going.
Can you say anything about how the e10s AWSY runs are going; or would I have to build and run my own copy to see what’s happening? With the initial e10s implementation only having a single content process (vs one per tab), I’d guess the only change would be a net upward shift due to the extra process overhead. I’d be happy to be proved wrong though; as slowly as the initial version is progressing I’m not holding my breath on more advanced versions coming out anytime soon.