2002520 - 3.04 - 2.98% Base Content JS / Base Content JS + 1 more (Linux, OSX, Windows) regression on Mon November 24 2025

Status: RESOLVED WONTFIX

(Core :: DOM: Navigation, defect)

Description

[Treeherder Bug Filer]

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

Please acknowledge, and begin investigating this alert within 3 business days, or the patch(es) may be backed out in accordance with our regression policy. Our guide to handling regression bugs has information about how you can proceed with this investigation.

If you have any questions or need any help with the investigation, please reach out to [e-mail]. Alternatively, you can find help on Slack by joining #perf-help, and on Matrix you can find help by joining #perftest.

Regressions:

Ratio	Test	Platform	Options	Absolute values (old vs new)
3%	Base Content JS	linux1804-64-shippable-qr	fission	1,544,732.00 -> 1,591,678.67
3%	Base Content JS	macosx1470-64-shippable	fission	1,541,148.00 -> 1,587,694.00
3%	Base Content JS	windows11-64-24h2-shippable	fission	1,543,480.00 -> 1,589,480.00

Details of the alert can be found in the alert summary, including links to graphs and comparisons for each of the affected tests.

If you need the profiling jobs you can trigger them yourself from treeherder job view or ask [e-mail] to do that for you.

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

The following documentation link provides more information about this command.

Comment 1

[Vincent Hilla [:vhilla]]

:hsivonen can we ignore this regression? My understanding is we're using 3% more memory for an empty content process.

Comment 2

[BugBot [:suhaib / :marco]]

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

Comment 3

[Henri Sivonen (:hsivonen)]

The increase under js-main-runtime is all under the runtime item. I suspect that we know have an about:blank in existence where we didn't have one before, and it gets associated SpiderMonkey resources that show up here.

Comment 4

[Andrew McCreight [:mccr8]]

This test loads about:blank in 4 different tabs, in case that helps. I'll try looking deeper into what the memory is in a few hours in case that helps. The basic strategy is to look at the treeherder job before and after the regression, and download the memory report, then use the diff functionality of about:memory.

Comment 5

[Andrew McCreight [:mccr8]]

I don't think the issue is js-main-runtime. The initially reported regression is in Base Content JS, which is in the total amount of JS in the content process.

Looking at the diff in about:memory of the reports before and after, I see this:

0.30 MB (100.0%) -- explicit
├──0.32 MB (105.18%) -- window-objects/top(about:blank, id=NNN)
│  ├──0.24 MB (78.41%) -- active/window(about:blank)
│  │  ├──0.23 MB (78.21%) -- js-realm(moz-nullprincipal:{NNNNNNNN-NNNN-NNNN-NNNN-NNNNNNNNNNNN}, about:blank)/classes
│  │  │  ├──0.20 MB (67.08%) ++ class(Function)/objects
│  │  │  └──0.03 MB (11.13%) ++ class(<non-notable classes>)/objects
[...]
│  └──0.08 MB (26.77%) -- js-zone(0xNNN)
│     ├──0.07 MB (24.70%) ── getter-setters-gc-heap [8] [+]
[...]
├──0.04 MB (13.24%) -- js-non-window
│  ├──0.04 MB (11.74%) -- zones/zone(0xNNN)
│  │  ├──0.05 MB (15.28%) -- strings/string(<non-notable strings>)

As I said, the way this test works is that it loads about:blank in 8 separate tabs, in 8 separate processes. From this, it looks like the change made about:blank itself a bit larger, but I think from the perspective of content process overhead we don't care, because normally we don't keep around the about:blank once we load a new page? Is that right? Also, is the slight increase in size expected?

Comment 6

[Vincent Hilla [:vhilla]]

Looking at AwsyTestCase.open_and_focus, the test uses

gBrowser.addTab("about:blank", {
  inBackground: false,
  triggeringPrincipal: Services.scriptSecurityManager.getSystemPrincipal(),
});

followed by marionette.navigate, which does CanonicalBrowsingContext::LoadURI("about:blank", ...) and waits for the load to complete.

That means that tab contains a non-initial about:blank and that should be unaffected by the changes. The initial about:blank from addTab that was replaced should not stay around, I think.

I'm a bit unsure where the null principal comes from. There is bug 1955324, but I thought that might not be valid anymore. But if it is, maybe having a system vs null principal causes the document size to change? Looking at the memory reports side by side, there is this additional js-realm(moz-nullprincipal:{87808264-068e-409f-9c1c-714494fd66c7}, about:blank). Edit: in both cases, nsDocShellLoadState::SetupInheritingPrincipal won't allow inheriting a system principal.

Comment 7

[Vincent Hilla [:vhilla]]

No, having addTab load a null principal doesn't change the memory usage.

Comment 8

[Vincent Hilla [:vhilla]]

Looking at Document leak logs, there is one less intermediate document, and it is destroyed sooner with bug 543435. They do stick around a bit longer than perhaps necessary.

Log extract before the change:

[Child 524321: Main Thread]: D/DocumentLeak DOCUMENT 7718fddd9e00 created
[Child 524321: Main Thread]: D/DocumentLeak DOCUMENT 7718fddd9e00 ResetToURI about:blank
[Child 524321: Main Thread]: D/DocumentLeak DOCUMENT 7718fddd9e00 with PressShell 7718fdbf7000 and DocShell 7718fdbc0d98
[Child 524321: Main Thread]: D/DocumentLeak DOCUMENT 7718fdddc500 created
[Child 524321: Main Thread]: D/DocumentLeak DOCUMENT 7718fdddc500 StartDocumentLoad about:blank
[Child 524321: Main Thread]: D/DocumentLeak DOCUMENT 7718fdddc500 ResetToURI about:blank
[Child 524321: Main Thread]: D/nsDocShell nsDocShell[7718fdbc0c00]::OnNewURI("about:blank", [about:blank], 0x1)
[Child 524321: Main Thread]: D/nsDocShell   shAvailable=1 updateSHistory=1 updateGHistory=1 equalURI=1
[Child 524321: Main Thread]: D/DocumentLeak DOCUMENT 7718fdddc500 with PressShell 7718fdb4d000 and DocShell 7718fdbc0d98
[Child 524321: Main Thread]: D/DocumentLeak DOCUMENT 7718fdddc500 UnblockDOMContentLoaded
 0:44.33 INFO switching to tab
 0:44.33 INFO switched to tab
 0:44.33 INFO loading about:blank
[Child 524321: Main Thread]: D/DocumentLeak DOCUMENT 7718fdddd200 created
[Child 524321: Main Thread]: D/DocumentLeak DOCUMENT 7718fdddd200 StartDocumentLoad about:blank
[Child 524321: Main Thread]: D/DocumentLeak DOCUMENT 7718fdddd200 ResetToURI about:blank
[Child 524321: Main Thread]: D/nsDocShell nsDocShell[7718fdbc0c00]::OnNewURI("about:blank", [about:blank], 0x200001)
[Child 524321: Main Thread]: D/nsDocShell   shAvailable=1 updateSHistory=1 updateGHistory=1 equalURI=1
[Child 524321: Main Thread]: D/DocumentLeak DOCUMENT 7718fdddd200 with PressShell 7718fefdf000 and DocShell 7718fdbc0d98
[Child 524321: Main Thread]: D/DocumentLeak DOCUMENT 7718fdddd200 UnblockDOMContentLoaded
 0:44.36 INFO loaded!
[Child 524028: Main Thread]: D/DocumentLeak DOCUMENT 7718fdd92e00 destroyed
[Child 524028: Main Thread]: D/DocumentLeak DOCUMENT 7718fdd95500 destroyed
[Child 524460: Main Thread]: D/DocumentLeak DOCUMENT 7718fde97900 created
[Child 524460: Main Thread]: D/DocumentLeak DOCUMENT 7718fde97900 ResetToURI about:blank
[Child 524460: Main Thread]: D/DocumentLeak DOCUMENT 7718fde97900 with PressShell 7718fdb08000 and DocShell 7718fdbc9598
[Child 524460: Main Thread]: D/DocumentLeak DOCUMENT 7718fde93800 created
[Child 524460: Main Thread]: D/DocumentLeak DOCUMENT 7718fde93800 StartDocumentLoad about:blank
[Child 524460: Main Thread]: D/DocumentLeak DOCUMENT 7718fde93800 ResetToURI about:blank
[Child 524460: Main Thread]: D/nsDocShell nsDocShell[7718fdbc9400]::OnNewURI("about:blank", [about:blank], 0x1)
[Child 524460: Main Thread]: D/nsDocShell   shAvailable=1 updateSHistory=1 updateGHistory=1 equalURI=1
[Child 524460: Main Thread]: D/DocumentLeak DOCUMENT 7718fde93800 with PressShell 7718fdb5d000 and DocShell 7718fdbc9598
[Child 524460: Main Thread]: D/DocumentLeak DOCUMENT 7718fde93800 UnblockDOMContentLoaded
 0:54.46 INFO switching to tab
 0:54.47 INFO switched to tab
 0:54.47 INFO loading about:blank
[Child 524460: Main Thread]: D/DocumentLeak DOCUMENT 7718fde94500 created
[Child 524460: Main Thread]: D/DocumentLeak DOCUMENT 7718fde94500 StartDocumentLoad about:blank
[Child 524460: Main Thread]: D/DocumentLeak DOCUMENT 7718fde94500 ResetToURI about:blank
[Child 524460: Main Thread]: D/nsDocShell nsDocShell[7718fdbc9400]::OnNewURI("about:blank", [about:blank], 0x200001)
[Child 524460: Main Thread]: D/nsDocShell   shAvailable=1 updateSHistory=1 updateGHistory=1 equalURI=1
[Child 524460: Main Thread]: D/DocumentLeak DOCUMENT 7718fde94500 with PressShell 7718fefd0000 and DocShell 7718fdbc9598
[Child 524460: Main Thread]: D/DocumentLeak DOCUMENT 7718fde94500 UnblockDOMContentLoaded
 0:54.49 INFO loaded!
[Child 524321: Main Thread]: D/DocumentLeak DOCUMENT 7718fddd9e00 destroyed
[Child 524321: Main Thread]: D/DocumentLeak DOCUMENT 7718fdddc500 destroyed

Log extract after the change

[Child 521702: Main Thread]: D/DocumentLeak DOCUMENT 7bedb4ed9e00 created
[Child 521702: Main Thread]: D/DocumentLeak DOCUMENT 7bedb4ed9e00 ResetToURI about:blank
[Child 521702: Main Thread]: D/DocumentLeak DOCUMENT 7bedb4ed9e00 with PressShell 7bedb4cf8000 and DocShell 7bedb4cc1998
[Child 521702: Main Thread]: D/nsDocShell nsDocShell[7bedb4cc1800]::DoURILoad sync about:blank onto initial about:blank. Document[7bedb4ed9e00]
[Child 521702: Main Thread]: D/DocumentLeak DOCUMENT 7bedb4ed9e00 UnblockDOMContentLoaded
[Parent 520839, Main Thread] WARNING: NS_ENSURE_TRUE(she && she->mInfo->mSharedState.Get()) failed: file /home/vincent/mozilla-unified/docshell/shistory/SessionHistoryEntry.cpp:1213
 0:54.83 INFO switching to tab
 0:54.83 INFO switched to tab
 0:54.83 INFO loading about:blank
[Child 521702: Main Thread]: D/DocumentLeak DOCUMENT 7bedb4edec00 created
[Child 521702: Main Thread]: D/DocumentLeak DOCUMENT 7bedb4edec00 StartDocumentLoad about:blank
[Child 521702: Main Thread]: D/DocumentLeak DOCUMENT 7bedb4edec00 ResetToURI about:blank
[Child 521702: Main Thread]: D/nsDocShell nsDocShell[7bedb4cc1800]::OnNewURI("about:blank", [about:blank], 0x200001)
[Child 521702: Main Thread]: D/nsDocShell   shAvailable=1 updateSHistory=1 updateGHistory=1 equalURI=1
[Child 521702: Main Thread]: D/DocumentLeak DOCUMENT 7bedb4edec00 with PressShell 7bedb3703000 and DocShell 7bedb4cc1998
[Child 521702: Main Thread]: D/DocumentLeak DOCUMENT 7bedb4edec00 UnblockDOMContentLoaded
 0:54.85 INFO loaded!
[Child 521509: Main Thread]: D/DocumentLeak DOCUMENT 7bedb4ed9e00 destroyed

Comment 9

[Vincent Hilla [:vhilla]]

Bug 2002870 mentions a leak in Thunderbird. It's possible similar issues exist in the Firefox frontend and could cause the js realm to leak.

Comment 10

[Henri Sivonen (:hsivonen)]

Also, is the slight increase in size expected?

One bitfield bit was added to Document, so a size increase is not expected.

It's possible similar issues exist in the Firefox frontend and could cause the js realm to leak.

I see substantially less traffic in both D/DocumentLeak and in D/DOMLeakInner after bug 543435 landed.

In both cases, I see 18 more DOMWINDOW creations than destructions:

$ rg 'DOMLeakInner DOMWINDOW [^ ]+ created' leaklog_after.txt | wc -l
34
$ rg 'DOMLeakInner DOMWINDOW [^ ]+ destroyed' leaklog_after.txt | wc -l
16
$ rg 'DOMLeakInner DOMWINDOW [^ ]+ created' leaklog_before.txt | wc -l
42
$ rg 'DOMLeakInner DOMWINDOW [^ ]+ destroyed' leaklog_before.txt | wc -l
24

mccr8, do you have insight into what to try next?

Comment 11

[Mayank Bansal]

There are some improvements:
1.5% on Base content resident unique

Plus similar improvements on many "first load" memory metrics. I checked on windows only.

Comment 12

[Andrew McCreight [:mccr8]]

resident-unique is way more important than JS, as it reflects actual memory, whereas JS by itself doesn't mean actual memory usage increased. Maybe this is just more memory being measured properly? I think this is fine then. Thanks everybody for investigating.