Pass sameZoneAs to sandbox constructor to make GCs cheaper

[the8472]

According to about:memory µMatrix sandboxes all seem to live within the same zone (in process/remote tab child global, depending on e10s).

As I understand it this has a negative impact on GC performance since allocations by scripts loaded into those sandboxes triggers GCs in this fairly large zone instead of GCing in a window-specific zone. I would guess that the the cross-zone references are also be more expensive.

This can be mitigated by using the sameZoneAs option.

The addon SDK does this for its sandboxes, so it's probably best practice.

[gorhill]

Thanks for the tip.

Apparently this option was not documented until last Jan 2015, so this might explain why it was not used originally. What specific entry in about:memory are you looking at?

[the8472]

1. go to about:memory
2. click measure
3. when measurement is done unfold explicit -> js-non-window -> zones
4. look for the zone that contains a compartment called outOfProcessTabChildGlobal (e10s, child process) or inProcessTabChildGlobal (non-e10s).

That's the global zone where all the chrome/browser.xul/addon/framescript stuff lives by default.

The tab-specific zones are listed under explicit -> window-objects

[gorhill]

Using uBlock (from where uMatrix's Firefox-specific code mostly come from), I measured the effect of using sameZoneAs, using the vim color test to ensure lots of mem allocations going on, and this is what I got:

sameZoneAs = undefined;:

├──125.73 MB (48.29%) -- window-objects/top(http://vimcolorschemetest.googlecode.com/svn/html/index-c.html, id=2147483649)
│  ├──121.51 MB (46.67%) ++ active
│  └────4.22 MB (01.62%) ++ js-zone(0x7facfd718800)
├───60.66 MB (23.30%) -- js-non-window
│   ├──54.05 MB (20.76%) -- zones
│   │  ├──53.29 MB (20.47%) ++ zone(0x7fad05b35000) <<<<<<<<<<<<<<<<

sameZoneAs = win.top;:

├──132.14 MB (49.91%) -- window-objects/top(http://vimcolorschemetest.googlecode.com/svn/html/index-c.html, id=2147483649)
│  ├──121.51 MB (45.90%) ++ active
│  └───10.63 MB (04.02%) ++ js-zone(0x7f07cae18800)
├───52.97 MB (20.01%) -- js-non-window
│   ├──46.04 MB (17.39%) -- zones
│   │  ├──38.65 MB (14.60%) ++ zone(0x7f07cae18800)
│   │  ├───6.63 MB (02.50%) ++ zone(0x7f07d3235000) <<<<<<<<<<<<<<<<

From the results, the main (significant) effect has been to move content scripts' allocations out of the common (long-lived) zone into the tab-specific zone: common zone size went from ~53 MB down to ~6.6 MB.

Not sure if this will have any noticeable effect to a user -- but nonetheless, this seems the proper way to do this.

allocations by scripts loaded into those sandboxes triggers GCs in this fairly large zone instead of GCing in a window-specific zone

If I understand what you are saying, zones are separate, independent memory arenas, and thus running a GC operation in one means the GC code will not stumble onto items from other arenas (zones)?

[the8472]

If I understand what you are saying, zones are separate, independent memory arenas, and thus running a GC operation in one means the GC code will not stumble onto items from other arenas (zones)?

yes, ideally it will have the following effects

a) the window and the sandbox can be discarded together, i.e. without having to GC the system zone
b) GCs in the system zone are cheaper because they don't have to touch the sandbox
c) GCs in the sandbox are cheaper because they don't have to touch the system zone

In practice those benefits may not be fully realized because there can be references crossing zone boundaries, keeping objects alive longer than necessary.

That can be further improved by either using weak references for anything pointing into the sandbox or by nuking the sandbox if you're holding onto a reference to it somewhere.

I see that you're registering message manager callbacks and have them point into the sandbox (I think?). Maybe using weak listeners would be appropriate there if the callbacks are kept alive by a field in the sandbox anyway.

But that's a second step, separating the zones might already provide some good improvement.