1842074 - Firefox's heap grows much bigger than Chrome's during a run of Speedometer3

Status: NEW

(Core :: Cycle Collector, defect)

Description

[Jeff Muizelaar [:jrmuizel]]

FF gets up to 1.27GB: https://share.firefox.dev/3XE9K5s
Chrome only gets to 333MB: https://share.firefox.dev/44QZmdd

Comment 1

[Andrew McCreight [:mccr8] (PTO until 12-2)]

It looks like we're not running the CC very much. Filtering the "flame graph" tab for "ccgraphbuilder", it looks like we run it very briefly around 28 seconds, then it doesn't run again until 70 seconds (when you see the first drop in memory). The CC tries to be deferential to the GC, so maybe it is backing off too much. If you instead filter on "gccycle", we are running the GC quite a bit.

Comment 2

[Andrew McCreight [:mccr8] (PTO until 12-2)]

So, at a first glance, I'd say the issue is probably about CC scheduling and not the CC running and failing to collect things.

Comment 3

[Andrew McCreight [:mccr8] (PTO until 12-2)]

We have kMaxCCLockedoutTime which is 30 seconds, though it is more than 40 seconds between CC runs. Maybe there's an extra delay of 10 seconds because we are okay with the GC running in that 10 seconds. You could set kMaxCCLockedoutTime to say 10 seconds and see if that makes some kind of difference in terms of memory. An alternate angle to tweak it would be to crank up the slice budget for the GC so it finishes faster.

Comment 4

[Jeff Muizelaar [:jrmuizel]]

I'll try those things.

Comment 5

[Jeff Muizelaar [:jrmuizel]]

kMaxCCLockedoutTime = 10s: https://share.firefox.dev/3XEcPm5, max = 1.52GB
mActiveIntersliceGCBudget = 50ms: https://share.firefox.dev/3D6qUzj, max = 516MB

Comment 6

[Andrew McCreight [:mccr8] (PTO until 12-2)]

That first one looks the same: the CC never runs (slightly worse: we miss the one run early for whatever reason). But if you search the second one for "nscyclecollector::collect" you can see that we're actually managing to run the CC regularly.

There's some logic in CCGCScheduler::ComputeInterSliceGCBudget that is supposed to increase the GC budget when the CC is locked out, but maybe it isn't being aggressive enough.

Comment 7

[Andrew McCreight [:mccr8] (PTO until 12-2)]

Spending a lot of time in the GC (bug 1821293) could be related to why the GC falls behind and locks out the CC.

Comment 8

[Andrew McCreight [:mccr8] (PTO until 12-2)]

I'm going to set this to S3 because I don't think the direct user impact is high here. This benchmark spams through a bunch of operations and pages much faster than any person will ever do it, so it stresses our delicate dance of GC and CC an unrealistic amount. We still probably want it to be P2 because we don't want the GC/CC to get in the way of testing the more interesting aspects of Speedometer3.

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

FWIW, last time I checked this (after which sp3 has gotten quite a few new subtests, so there might very well be new issues now) CC couldn't release too much memory since JS was keeping stuff alive, at least through bug 1821293.

Comment 10

[Andrew McCreight [:mccr8] (PTO until 12-2)]

Jeff's mActiveIntersliceGCBudget = 50ms link shows that the CC running enough is actually an issue. Though I guess now 3 bugs have been closed blocking bug 1821293 so maybe there's more room to free stuff now.

Comment 11

[Denis Palmeiro [:denispal]]

Attachment: chrome_vs_firefox_RSS.png

Out of curiosity, I tried measuring the patch in https://bugzilla.mozilla.org/show_bug.cgi?id=1821293#c1 and also disabling pointer compression in v8. The numbers seem much closer afterwards.