Perfherder has detected a awsy performance regression from push 8bee937821e3725b922352a0493f53b5e431c3d0. As author of one of the patches included in that push, we need your help to address this regression.

Regressions:

Details of the alert can be found in the alert summary, including links to graphs and comparisons for each of the affected tests. Please follow our guide to handling regression bugs and let us know your plans within 3 business days, or the offending patch(es) will be backed out in accordance with our regression policy.

For more information on performance sheriffing please see our FAQ.

Is this really caused by bug 1711610? I think bug 1711610 impacts only Windows.

Could this affect the behavior on other platforms when we trigger a manual minimize memory notification? The AWSY tests do that.

No, this reduces a chance to trigger memory-pressure events on Windows. There is no change on the behaviors after memory notifications are triggered.

Set release status flags based on info from the regressing bug 1711610

Andra, could you retriage the regression?

This is a pretty large regression so we should really figure out what is going on here.

(In reply to Marco Castelluccio [:marco] from comment #5)

Andra, could you retriage the regression?

I did some retriggers. The graph is pretty clear and the regression seems to be here.

[Tracking Requested - why for this release]: large regression in content process memory overhead, though it is possible that this is some kind of measurement artifact.

I downloaded the memory-report-TabsOpenForceGC-0.json.gz artifacts before and after the regression, then compared them using "load and diff" in about:memory. "web" is the relevant process.

On Linux, the regression looks like this:

4.84 MB (100.0%) -- explicit
├──4.88 MB (100.73%) -- heap-overhead
│ ├──4.91 MB (101.53%) ── page-cache [8]

OSX and Windows look similar.

Maybe there's some mechanism to purge the page-cache on memory minimization that got broken?

Ah, now I see the problem. An OS-independent part in my patch is I moved AvailableMemoryTracker::Init() from NS_InitXPCOM to XREMain::XRE_mainRun() to use prefs. This broke memory-pressure in the child processes entirely because XRE_mainRun() is only for the main process. Apparently this is my bad! I'll prepare a patch.

Bug 1711610 moved AvailableMemoryTracker::Init() from NS_InitXPCOM to XRE_mainRun,
but it caused memory degradation because AvailableMemoryTracker was no longer initialized
in the child processes.

I made that part for nsAvailableMemoryWatcher to cache the pref value in the earlier design,
but it's not needed at all in the current design because nsAvailableMemoryWatcher loads
a mirror value every time.

This patch reverts AvailableMemoryTracker::Init() back to NS_InitXPCOM.

I started a Try job with a patch: https://treeherder.mozilla.org/jobs?repo=try&revision=0b2e8348281b59938e4ef471bf210918edb644c5. How can I kick performance tests and verify the patch before landing?

The base overhead tests show up as SY(ab). You can find them by doing "add new jobs (search)" and searching for "awsy base". Then you can use perf herder to compare the results to the existing ones.

Ok, here's a link to Perfherder. I can see the patch is bringing up performance. Thank you for the help!

https://treeherder.mozilla.org/perfherder/compare?originalProject=try&originalRevision=2d9f0efe78d9c45e0727b1650cd5fe6bf8bd03a2&newProject=try&newRevision=0b2e8348281b59938e4ef471bf210918edb644c5&framework=4

https://hg.mozilla.org/mozilla-central/rev/cee641108aa0

The patch landed in nightly and beta is affected.
:toshi, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

== Change summary for alert #30310 (as of Mon, 07 Jun 2021 09:55:01 GMT) ==

Improvements:

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=30310

Comment on attachment 9225004 [details]
Bug 1713100 - Move AvailableMemoryTracker::Init() back to NS_InitXPCOM. r=gsvelto

Beta/Release Uplift Approval Request

• User impact if declined: Firefox consumes 7-8% more memory on all platforms because no memory-pressure events are issued in child processes.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This is a regression from bug 1711610 and the fix is to partially revert the regressing change into the original. No new logic was implemented by this patch.
• String changes made/needed: None

Comment on attachment 9225004 [details]
Bug 1713100 - Move AvailableMemoryTracker::Init() back to NS_InitXPCOM. r=gsvelto

approved for 90.0b5

https://hg.mozilla.org/releases/mozilla-beta/rev/a9109eade399

== Change summary for alert #30363 (as of Mon, 14 Jun 2021 14:41:51 GMT) ==

Improvements:

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=30363