1837937 - Investigate better scheduling for minorGC

Status: NEW

(Core :: JavaScript: GC, task, P2)

Description

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

Based on the profiles we do trigger minorGC too often while running speedometer3 [1][2].
We don't seem to utilize idle time basically at all for minorGC and when minorGC runs while running the benchmark, it often shrinks the nursery size and then needs to increase it again.
Just a rather dummy tweak, increase the size and don't shrink:
https://treeherder.mozilla.org/perfherder/compare?originalProject=try&originalRevision=af826c464f71d7553bb2731e752e7cc5a0970e24&newProject=try&newRevision=036b2c88e3500e24fb56b732e14702b9e574285d
That reveals how much difference minorGC scheduling/size may make.

My guess is that we should be less eager to decrease nursery size and utilize idle time more. There should be small slices of idle time rather often.

[1] https://speedometer-preview.netlify.app
[2] https://speedometer-preview.netlify.app/?developerMode

Comment 1

[Paul Bone [:pbone]]

Some time ago Yoshi (I think, or maybe it was another person) added code to drive minor GC from idle time. So there might be some existing code on this that needs tweaking, if it's still there - I haven't looked in some time.

Comment 2

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

There is some code, but that doesn't seem to get run too often. I think on the main thread we might rely on the idletaskrunner and wait a bit too long time before trying to find idle time. And also, it is possible that we just don't exceed the limits often enough.
It might be reasonable to try to collect nursery heap rather often, but not shrink it so easily.

Comment 3

[Jon Coppeard (:jonco)]

Agreed we can probably tune this better.

However making the nursery slower to shrink will regress AWSY unless we are careful. We use one nursery per runtime, which means several per process because of web workers, and this amplifies differences here.

Also, collecting the nursery more often effectively reduces its size which will reduce the performance gain from using it.

Comment 4

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

We wouldn't need to shrink nursery so often or so much when running minorGC, right?
Atm based on the profiles at least we're rather eager in shrinking the nursery size.

Only increasing nursery size improves sp3 ~0.8%
https://treeherder.mozilla.org/perfherder/comparesubtest?originalProject=try&newProject=try&newRevision=06255d346e0464c815f19f6e522724d7c98c5616&originalSignature=4586009&newSignature=4586009&framework=13&application=firefox&originalRevision=af826c464f71d7553bb2731e752e7cc5a0970e24&page=1&showOnlyConfident=1

When adding also a dummy tweak to targetSize(), https://hg.mozilla.org/try/rev/9f9d13f44ab307e4d98b3909d1ae854191d6e3a5
the improvement is 1.45%
https://treeherder.mozilla.org/perfherder/comparesubtest?originalProject=try&newProject=try&newRevision=036b2c88e3500e24fb56b732e14702b9e574285d&originalSignature=4586009&newSignature=4586009&framework=13&application=firefox&originalRevision=af826c464f71d7553bb2731e752e7cc5a0970e24&page=1

Neither of those changed idle handling.

But those were just some simple things I tried.

And we could have smaller nurseries for workers, and perhaps also in those processes which have only background tabs?
(in other words, do something similar what we do with mozjemalloc dirty pages, bug 1815069)

Comment 5

[Jan de Mooij [:jandem]]

Olli, is this better now after some of the changes you made last year? I'm triaging our perf bugs to see which ones are still relevant.

Comment 6

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

It is better, but MinorGC still shows up heavily in the profiles. Somehow we still shrink nursery size every now and then too much.