Closed Bug 1645510 Opened 4 years ago Closed 4 years ago

Create the unprivileged junk scope lazily, and hold it weakly

Categories

(Core :: XPConnect, task)

Product:
Core
Component:
XPConnect
Type:
task

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla79
Tracking Flags:
Tracking Status
firefox79 --- fixed

People

(Reporter: kmag, Assigned: kmag)

References

(Blocks 1 open bug)

Details

(Keywords: perf-alert)

Attachments

(4 files)

Bug 1645510: Part 0 - Handle first system zone compartment having system principal. r=jandem
(deleted), text/x-phabricator-request
Details
Bug 1645510: Part 1 - Make unprivileged junk scope creation lazy, weak, and fallible. r=bholley,mccr8
(deleted), text/x-phabricator-request
Details
Bug 1645510: Part 2 - Avoid using the unprivileged junk scope where possible. r=bholley
(deleted), text/x-phabricator-request
Details
Bug 1645510: Part 3 - Make some UnprivilegedJunkScope calls fallible. r=mccr8
(deleted), text/x-phabricator-request
Details

In the best case, the unprivileged junk scope occupies at least 10KB of memory per content process, even if it's never used. When it is used for ephemeral objects, that number climbs even higher as lazy prototypes for built-in objects are instantiated and then held alive forever.

We can solve both of these problems by only creating the global when it's needed, and letting it get GCed when none of the objects that were created in it are left to hold it alive.

Looks like you dropped a word from the summary.

Summary: Create the unprivileged junk scope, and hold it weakly → Create the unprivileged junk scope lazily, and hold it weakly

Prior to this patch set, XPConnect always created the first compartment in the
system zone with a content principal. The subsequent patches make that
global's creation lazy, which leads us to create the first compartment in the
system zone with the system principal and the NewCompartmentInSystemZone
specifier. In that case, we call setIsSystemZone() when we create the zone,
because the compartment has the system principal, and then call it again when
we try to store it in rt->gc.systemZone, which leads to a failed assertion.

This patch fixes that.

Attachment #9156783 - Attachment description: Bug 1645510: Part 1 - Make unprivileged junk scope creation lazy, weak, and fallible. r=mccr8 → Bug 1645510: Part 1 - Make unprivileged junk scope creation lazy, weak, and fallible. r=bholley,mccr8
Attachment #9156784 - Attachment description: Bug 1645510: Part 2 - Use JSM global rather than unprivileged junk scope where appropriate. r=mccr8 → Bug 1645510: Part 2 - Avoid using the unprivileged junk scope where possible. r=bholley
Pushed by maglione.k@gmail.com: https://hg.mozilla.org/integration/autoland/rev/56434e256a52 Part 0 - Handle first system zone compartment having system principal. r=jandem https://hg.mozilla.org/integration/autoland/rev/821960c5fa97 Part 1 - Make unprivileged junk scope creation lazy, weak, and fallible. r=mccr8,bholley https://hg.mozilla.org/integration/autoland/rev/93bca0225002 Part 2 - Avoid using the unprivileged junk scope where possible. r=bholley https://hg.mozilla.org/integration/autoland/rev/a6b021b3776a Part 3 - Make some UnprivilegedJunkScope calls fallible. r=mccr8

== Change summary for alert #26362 (as of Sat, 27 Jun 2020 23:27:31 GMT) ==

Improvements:

1% Base Content JS macosx1014-64-shippable opt 3,552,944.17 -> 3,533,568.67
0.48% Base Content JS linux1804-64-shippable-qr opt 3,536,240.67 -> 3,519,154.67
0.47% Base Content JS linux1804-64-shippable opt 3,536,002.67 -> 3,519,258.33
0.36% Base Content JS windows10-64-shippable-qr opt 3,593,522.00 -> 3,580,680.00

For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=26362

Keywords: perf-alert
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: