Make [System Principal] into a static atom
Categories
(Core :: XPCOM, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox68 | --- | fixed |
People
(Reporter: mccr8, Assigned: mccr8)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
[System Principal] gets turned into an atom in every process that runs chrome JS, so we might as well make it into a static atom and save a little memory. A side benefit, and my major motivation, is that it is a bandaid fix for the annoying OSX atom assertion (seen in bug 1525411) when we leak chrome JS.
My first instinct is that it would make sense to use this new atom directly in SystemPrincipal, but atoms are represented internally as a kind of nsAString, but principal code uses nsACStrings, so you end up with an extra conversion from 16-bit to 8-bit.
I might add some other static atoms for various events like onMozLocalStorageChanged at the same time, because touching this file turns out to cause quite a massive rebuild.
Assignee | ||
Comment 1•5 years ago
|
||
Whenever chrome JS code leaks, we leak the dynamic atom "[System
Principal]". This causes an assertion, which hangs the browser in
stack walking code for multiple minutes on OSX. As a bandaid, make
this atom static so it won't leak.
My first instinct is that it would make sense to use this new atom
directly in SystemPrincipal, but atoms are represented internally as a
kind of nsAString, but principal code uses nsACStrings, so you end up
with an extra conversion from 16-bit to 8-bit.
This atom is also going to be present in any process running chrome
JS, so this will save a little bit of memory.
Assignee | ||
Comment 2•5 years ago
|
||
I skipped the event atoms. It seemed a little weird. There are about 50 that showed up a bunch of content processes when I loaded some web pages.
Pushed by amccreight@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/f09e9d011ba1 Make [System Principal] into a static atom. r=froydnj
Comment 4•5 years ago
|
||
bugherder |
Description
•