Closed Bug 1928943 Opened 3 months ago Closed 3 months ago

34316.95 - -3932% browser-console:parent-process memory / browser-console:parent-process memory (Linux) regression on Tue October 29 2024

Categories

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

defect

Tracking

()

RESOLVED FIXED
134 Branch
Tracking Status
firefox-esr128 --- unaffected
firefox132 --- unaffected
firefox133 --- unaffected
firefox134 --- fixed

People

(Reporter: intermittent-bug-filer, Assigned: ochameau)

References

(Blocks 1 open bug, Regression)

Details

(4 keywords)

Attachments

(1 file)

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

Regressions:

Ratio Test Platform Options Absolute values (old vs new)
34317% browser-console:parent-process memory linux1804-64-tsan-qr 279,893.33 -> 96,330,752.00
-3932% browser-console:parent-process memory linux1804-64-tsan-qr -2,581,162.67 -> 98,910,208.00

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 patch(es) may be backed out in accordance with our regression policy.

If you need the profiling jobs you can trigger them yourself from treeherder job view or ask a sheriff to do that for you.

You can run all of these tests on try with ./mach try perf --alert 42430

The following documentation link provides more information about this command.

For more information on performance sheriffing please see our FAQ.

If you have any questions, please do not hesitate to reach out to nchevobbe@mozilla.com.

Flags: needinfo?(jcoppeard)

Given the number that we're seeing, I'm wondering if there might be an issue in our memory tests

These tests are run on tsan platform..Is that platform tracked for regressions?
FWIW, on the corresponding Linux-180464 platform, there doesnt appear to be any noticeable regression.
And the tsan regression goes down (below the previous baseline) here.

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

Since this is a measurement in the parent process I suspect that this is a race condition and something has made GC run at slightly different times there.

ochameau do you happen to know what is being measured here and how? I found the test script but I can't really see what this is doing.

Flags: needinfo?(jcoppeard) → needinfo?(poirot.alex)
Assignee: nobody → poirot.alex
Status: NEW → ASSIGNED

Right, this is only a timing issue which goes completely off on tsan. To start with, we should not have a negative number... it would mean that opening the browser console would reduce the memory usage, which is a false claim.

These tests should only run on regular opt builds, not on tsan...

I verified locally, on regular builds, this tests doesn't regress. There may only be a higher variance in the resident memory consumption.

Flags: needinfo?(poirot.alex)
Pushed by apoirot@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/89128774a49c [devtools] Avoid running DevTools allocation tests on tsan. r=devtools-reviewers,nchevobbe
Blocks: GC
Severity: -- → S3
Priority: -- → P2
Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → 134 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: