Closed Bug 673208 Opened 13 years ago Closed 13 years ago

Many about:blank compartments at start-up with browser.sessionstore.max_concurrent_tabs=0

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 681201

People

(Reporter: ehsan.akhgari, Unassigned)

Details

(Whiteboard: [MemShrink:P2]) 

This is what I saw in about:memory:

│  ├────5,242,186 B (01.49%) -- compartment(about:blank)
│  │    ├──4,968,448 B (01.41%) -- gc-heap
│  │    │  ├──1,714,480 B (00.49%) -- objects
│  │    │  ├──1,592,304 B (00.45%) -- arena-unused
│  │    │  ├──1,553,408 B (00.44%) -- shapes
│  │    │  ├─────79,144 B (00.02%) -- arena-padding
│  │    │  ├─────29,112 B (00.01%) -- arena-headers
│  │    │  ├──────────0 B (00.00%) -- strings
│  │    │  └──────────0 B (00.00%) -- xml
│  │    ├────263,456 B (00.07%) -- object-slots
│  │    ├─────10,282 B (00.00%) -- scripts
│  │    ├──────────0 B (00.00%) -- string-chars
│  │    ├──────────0 B (00.00%) -- mjit-code
│  │    ├──────────0 B (00.00%) -- mjit-data
│  │    ├──────────0 B (00.00%) -- tjit-code
│  │    └──────────0 B (00.00%) -- tjit-data
│  │               ├──0 B (00.00%) -- allocators-main
│  │               └──0 B (00.00%) -- allocators-reserve

Using 5MB of memory for a document which definitely doesn't include any js at all seems wasteful.  Do we create a compartment for *every* document, regardless of whether it includes one js or not?
> for a document which definitely doesn't include any js at all

Are you sure?  Nothing stops someone from sticking a <script> tag in there via the DOM, and people often do on the web...  Or just building a DOM inside it.

But yes, we generally have a compartment for every document; for example the actual JSObject for that document (which exists if JS from _outside_ the document touches it) needs to come from that compartment.

All that said, I'm a little confused by how we ended up with a compartment labeled as about:blank, since the principal should generally be inherited by about:blank from whatever opened it....
I must also add that I got this *right after* I opened up Firefox, with only two tabs open (+ about:memory?verbose, of course).  Does that help narrow things down?
In that case, that sounds like the hidden window....
Esp. if you're not on Mac.
(In reply to comment #4)
> Esp. if you're not on Mac.

I am on Mac.
In that case, I can't reproduce that with a clean profile...
(In reply to comment #6)
> In that case, I can't reproduce that with a clean profile...

Well, my profile is far from clean.  :-)

The reason that I filed this bug is that I don't think that we should be creating compartments for js-less stuff.  Can we keep this bug open for that purpose?
I changed the title accordingly;  please change again if I mis-summarized.
Summary: about:blank needs a compartment → about:blank has a 5MB JS heap on start-up?
Compartments are used for both code and data.  If there are JSObjects attached to the page (e.g. if chrome script has touched the window and document in that page, which it probably has), then those JSObjects need to go into some compartment....

Now I agree that just about:blank itself should not use 5MB; that's worth looking into.
I just failed to reproduce on Linux64.  Steps:

- Start Firefox with a moderately-used profile, no add-ons enabled.  Firefox shows about:home in the 1st tab.

- Open about:memory?verbose in that 1st tab.  I see two about:blank compartments, but they're quite small:

│  ├─────146,222 B (00.25%) -- compartment(about:blank)
│  │     ├──135,168 B (00.24%) -- gc-heap
│  │     │  ├───48,072 B (00.08%) -- objects [2]
│  │     │  ├───47,816 B (00.08%) -- arena-unused [2]
│  │     │  ├───36,480 B (00.06%) -- shapes [2]
│  │     │  ├────1,976 B (00.00%) -- arena-padding [2]
│  │     │  ├──────792 B (00.00%) -- arena-headers [2]
│  │     │  └───────32 B (00.00%) -- strings
│  │     ├───10,160 B (00.02%) -- object-slots [2]
│  │     ├──────872 B (00.00%) -- scripts [2]
│  │     └───────22 B (00.00%) -- string-chars

(The "[2]" means that two reporters with the same paths were merged, which indicates there are two about:blank compartments.)

If do the same steps, but open about:memory?verbose in a second tab, I get this:

│  ├─────336,044 B (00.77%) -- compartment(about:blank)
│  │     ├──311,296 B (00.71%) -- gc-heap
│  │     │  ├──113,408 B (00.26%) -- objects [4]
│  │     │  ├──101,088 B (00.23%) -- arena-unused [4]
│  │     │  ├───90,176 B (00.21%) -- shapes [4]
│  │     │  ├────4,736 B (00.01%) -- arena-padding [4]
│  │     │  ├────1,824 B (00.00%) -- arena-headers [4]
│  │     │  └───────64 B (00.00%) -- strings [2]
│  │     ├───22,960 B (00.05%) -- object-slots [4]
│  │     ├────1,744 B (00.00%) -- scripts [4]
│  │     └───────44 B (00.00%) -- string-chars [2]

In both cases if I force a GC+CC the about:blank compartments disappear.


So the question is:  why does Ehsan see 5MB for these compartments?
(In reply to comment #10)
> So the question is:  why does Ehsan see 5MB for these compartments?

Not sure, can you try Mac, too?

I just opened up about:memory?verbose, and there I see it again:

│  ├────5,075,800 B (00.74%) -- compartment(about:blank)
│  │    ├──4,808,704 B (00.70%) -- gc-heap
│  │    │  ├──1,668,880 B (00.24%) -- objects [49]
│  │    │  ├──1,522,560 B (00.22%) -- arena-unused [49]
│  │    │  ├──1,512,448 B (00.22%) -- shapes [49]
│  │    │  ├─────76,608 B (00.01%) -- arena-padding [49]
│  │    │  ├─────28,176 B (00.00%) -- arena-headers [49]
│  │    │  ├─────────32 B (00.00%) -- strings [49]
│  │    │  └──────────0 B (00.00%) -- xml [49]
│  │    ├────256,136 B (00.04%) -- object-slots [49]
│  │    ├─────10,920 B (00.00%) -- scripts [49]
│  │    ├─────────40 B (00.00%) -- string-chars [49]
│  │    ├──────────0 B (00.00%) -- mjit-code [49]
│  │    ├──────────0 B (00.00%) -- mjit-data [49]
│  │    ├──────────0 B (00.00%) -- tjit-code [49]
│  │    └──────────0 B (00.00%) -- tjit-data
│  │               ├──0 B (00.00%) -- allocators-main [49]
│  │               └──0 B (00.00%) -- allocators-reserve [49]
Ok, the key thing is the "[49]" -- why does Ehsan have 49 about:blank compartments on start-up when I have 2?  Ehsan, any add-ons installed?
(In reply to comment #12)
> Ok, the key thing is the "[49]" -- why does Ehsan have 49 about:blank
> compartments on start-up when I have 2?  Ehsan, any add-ons installed?

Yes, I have lots of add-ons installed (this is my main profile).  I'm not sure whether we're ignoring the memshrink bugs caused by add-ons for now or not.
IMO it depends greatly on the popularity of the add-ons.  Eg. if there's a problem with AdBlock Plus, that's important.  Problems with the add-on SDK are even more important.  Problems with uncommonly used add-ons (e.g. bug 672619) aren't high priority.
So: what add-ons do you have installed?  Can you try disabling them selectively to determine if one or two are responsible for most of the about:blank compartments?
Yes, I'll do that soon.
Assignee: general → ehsan
So, when I copied all of my extensions to a new profile and started up Firefox, I now have only 358KB in 4 about:blank compartments...
OK, figured this out.  I had the browser.sessionstore.max_concurrent_tabs pref set to 0, in order to get a BarTab like functionality by making Firefox not load a tab until I switch to it.  Apparently we create one about:blank compartment per not-yet-loaded tab.  Resetting that pref to its default value (3) and waiting for all of the pages to open cause about:blank to only consume 450KB of memory for 4 reporters:

│    ├──────451,677 B (00.03%) -- compartment(about:blank)
│    │      ├──413,696 B (00.03%) -- gc-heap
│    │      │  ├──164,416 B (00.01%) -- objects [4]
│    │      │  ├──147,008 B (00.01%) -- shapes [4]
│    │      │  ├───93,096 B (00.01%) -- arena-unused [4]
│    │      │  ├────6,752 B (00.00%) -- arena-padding [4]
│    │      │  └────2,424 B (00.00%) -- arena-headers [4]
│    │      ├───26,352 B (00.00%) -- object-slots [4]
│    │      ├────9,472 B (00.00%) -- property-tables [4]
│    │      └────2,157 B (00.00%) -- scripts [4]
Assignee: ehsan → nobody
Nice detective work, Ehsan.

So, do we care about this?  Seems hard to avoid, and not that big a deal.
Summary: about:blank has a 5MB JS heap on start-up? → Many about:blank compartments at start-up with browser.sessionstore.max_concurrent_tabs=0
Those not-yet-loaded tabs do in fact have about:blank loaded in them.....
(In reply to comment #20)
> Those not-yet-loaded tabs do in fact have about:blank loaded in them.....

Is there any reason for those about:blank's to have script compartments?

As for whether or not we care about this, I don't know.  But we may be doing the same thing in other parts of the code.  I guess this is not a huge MemShrink item, but maybe we can put it in the P3 bucket?  It just seems wasteful to me...
> Is there any reason for those about:blank's to have script compartments?

See comment 9.
Whiteboard: [MemShrink] → [MemShrink:P2]
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.