Closed Bug 624980 Opened 14 years ago Closed 9 years ago

Put each window in its own compartment

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: gal, Assigned: gal)

Details

Attachments

(1 file)

      No description provided.
Assignee: nobody → gal
Attached patch patchSplinter Review
gregor, want to give this a spin? shaver suggested looking at techcrunch (in particular a page with many comments)
So the patch makes each non-chrome DOMWindow to have its own compartment?
Does having lots of compartments use significantly more memory than
the current setup?
I did a quick test with about 15 open tabs (youtube, techcrunch, amazon, yahoo...)

I am logging the number of compartments and crossCompartmentWrappers at the beginning of each GC.

The current situation looks like:
Compartments: 37, CrossCompartmentWrappers: 3944
Compartments: 35, CrossCompartmentWrappers: 2960
Compartments: 35, CrossCompartmentWrappers: 4678
Compartments: 35, CrossCompartmentWrappers: 1770
Compartments: 35, CrossCompartmentWrappers: 1772
Compartments: 35, CrossCompartmentWrappers: 1770
Compartments: 36, CrossCompartmentWrappers: 5228
Compartments: 36, CrossCompartmentWrappers: 32
Compartments: 21, CrossCompartmentWrappers: 32
Compartments: 21, CrossCompartmentWrappers: 0
Compartments: 3, CrossCompartmentWrappers: 0
Compartments: 3, CrossCompartmentWrappers: 0
Compartments: 1, CrossCompartmentWrappers: 0

The same setup with this patch looks like:
Compartments: 159, CrossCompartmentWrappers: 4678
Compartments: 135, CrossCompartmentWrappers: 3085
Compartments: 100, CrossCompartmentWrappers: 5363
Compartments: 100, CrossCompartmentWrappers: 4086
Compartments: 100, CrossCompartmentWrappers: 1894
Compartments: 100, CrossCompartmentWrappers: 1907
Compartments: 101, CrossCompartmentWrappers: 5592
Compartments: 100, CrossCompartmentWrappers: 16
Compartments: 67, CrossCompartmentWrappers: 16
Compartments: 67, CrossCompartmentWrappers: 16

So the number of compartment increases but the crossCompartmentPointers stay pretty much the same.

Most of the crossCompartmentWrappers are created from techcrunch.
Opening just techcrunch looks like:
Compartments: 15, CrossCompartmentWrappers: 3579, not into default: 3579
Compartments: 12, CrossCompartmentWrappers: 6595, not into default: 6595
Compartments: 12, CrossCompartmentWrappers: 3412, not into default: 3412
Compartments: 11, CrossCompartmentWrappers: 3054, not into default: 3054
Memory related the current situation for techcrunch looks like:
Thanks to shaver that's very easy now :)

The highest value I see is:
Memory mapped: 204,677,120
Memory in use: 168,570,336

After a about 10 sec it gets stable at
Memory mapped: 186,155,008
Memory in use: 133,580,512

Again with compartment count at the beginning of each GC.
Compartments: 15, CrossCompartmentWrappers: 4041
Compartments: 12, CrossCompartmentWrappers: 2218
Compartments: 11, CrossCompartmentWrappers: 2167
Compartments: 11, CrossCompartmentWrappers: 2163
Compartments: 12, CrossCompartmentWrappers: 2163

With this patch it starts with:
Memory mapped: 297,566,208
Memory in use: 273,294,544

The highest value I see:
Memory mapped: 412,774,400
Memory in use: 390,424,880

After about 10 sec it becomes stable at:
Memory mapped: 264,671,232
Memory in use: 206,679,920

And compartment count again:					
Compartments: 139, CrossCompartmentWrappers: 5049
Compartments: 99, CrossCompartmentWrappers: 3081
Compartments: 57, CrossCompartmentWrappers: 2678
Compartments: 59, CrossCompartmentWrappers: 2774
Compartments: 55, CrossCompartmentWrappers: 3623
Compartments: 53, CrossCompartmentWrappers: 2483
Gregor, what do the numbers for gmail look like? I think they use a bunch of hidden iframes with a bunch of inter-window communication.
For entering Gmail:
again with memory peak, stable after few sec and compartment count.

Memory mapped: 154,742,784
Memory in use: 108,622,800

Memory mapped: 136,409,088
Memory in use: 88,547,568

Compartments: 7, CrossCompartmentWrappers: 365
Compartments: 4, CrossCompartmentWrappers: 305		

with patch:
Memory mapped: 173,486,080
Memory in use: 131,605,008

Memory mapped: 158,265,344
Memory in use: 116,704,368

Compartments: 16, CrossCompartmentWrappers: 3134
Compartments: 15, CrossCompartmentWrappers: 2113
Compartments: 17, CrossCompartmentWrappers: 3777
There is a bug that we bloat half a meg per compartment, supposedly. That might explain some of this.
gregor, can you try with that patch applied?
for opening 50 tabs with random pages it looks like:
Memory mapped:840,142,848
Memory in use:777,267,104
			
Compartments: 87, CrossCompartmentWrappers: 7292
Compartments: 87, CrossCompartmentWrappers: 7292
Compartments: 87, CrossCompartmentWrappers: 7292

with this patch:			
Memory mapped:1,046,077,440
Memory in use:864,203,344
						
Compartments: 169, CrossCompartmentWrappers: 8692
Compartments: 165, CrossCompartmentWrappers: 5001
Compartments: 167, CrossCompartmentWrappers: 8690

It seems that techcrunch is an exception.
(In reply to comment #10)
> gregor, can you try with that patch applied?

The patches from bug 623428 help a lot!


50 tabs with patches from bug 623428

Memory mapped: 671,186,944
Memory in use: 576,068,176

and with this patch:
Memory mapped: 742,637,568
Memory in use: 611,150,512

techcrunch:
Memory mapped: 178,458,624
Memory in use: 122,190,576

with this patch:
Memory mapped:209,620,992
Memory in use:132,958,608
The gmail case worries me, in particular if we regress performance due to cross-compartment property access being slower (or is it not?).
This sounds like compartment-per-global, which landed a while ago.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: