1439466 - Document mapping between tabs/iframes and compartments/zones

Status: RESOLVED FIXED

(Core :: JavaScript: GC, enhancement, P2)

Description

[Paul Bone [:pbone]]

Whenever I try to find out how Compartments and Zones map to browser concepts like tabs, documents and iframes I get answers like "soft of" and "it's complicated".  I don't want to blame anyone, but since this _is_ complicated I would like for us to find this information out and document it clearly.

Comment 1

[Steve Fink [:sfink] [:s:]]

On IRC, smaug pointed to

https://searchfox.org/mozilla-central/rev/47cb352984bac15c476dcd75f8360f902673cb98/dom/base/nsGlobalWindowOuter.cpp#1584

<smaug> tabs share the same zone, and tabgroups seem to share zone groups

// Two browsing contexts are considered "related" if they are reachable from one
// another through window.opener, window.parent, or window.frames. This is the
// spec concept of a "unit of related browsing contexts"
//
// Two browsing contexts are considered "similar-origin" if they can be made to
// have the same origin by setting document.domain. This is the spec concept of
// a "unit of similar-origin related browsing contexts"
//
// A TabGroup is a set of browsing contexts which are all "related". Within a
// TabGroup, browsing contexts are broken into "similar-origin" DocGroups. In
// more detail, a DocGroup is actually a collection of documents, and a
// TabGroup is a collection of DocGroups. A TabGroup typically will contain
// (through its DocGroups) the documents from one or more tabs related by
// window.opener. A DocGroup is a member of exactly one TabGroup.

And then jandem pointed out that cooperative scheduling is getting ripped out. So we may not have zone groups for much longer?

Comment 2

[Steve Fink [:sfink] [:s:]]

Note that I am not implying that this is a complete answer. I guess it might be if you know what window.opener and friends are. But it's not enough for *me* to have a complete understanding.

Comment 3

[Paul Bone [:pbone]]

Thank you,

That is helpful, but doesn't answer my questions yet.

Comment 4

[Jason Orendorff [:jorendorff]]

Jan knows things, and I can type "//" on many lines of text, so we might make a good team here

Comment 5

[Jan de Mooij [:jandem]]

So this is my current understanding, I don't know if the browser parts are 100% accurate. Let me know if anything is missing or unclear.

Compartment/global
------------------
* Since compartment-per-global, a compartment is basically "data associated with some global object". Every compartment has one global object, every global object belongs to one compartment.

* Compartments have important security properties. When compartment A wants to reference an object in compartment B, a wrapper (implemented as a proxy) is needed. There are different kinds of wrappers depending on how the compartments are related. For instance, same-origin wrappers will be transparent; different-origin wrappers may deny access to the wrapped object.

* The wrapper mechanism also allows us to "nuke" compartments by transplanting the wrapper with a "dead object proxy". This is used to avoid chrome -> content leaks (cutting wrappers lets the GC collect the content compartment).

* Each tab/frame/iframe in the browser has its own global object, so they must have their own compartment.

Zone
----
* A zone is just a JS engine optimization (it's not a security boundary) to group compartments that have similar lifetimes. Gecko uses a separate zone for each tab - this is nice because when the user closes a tab, all resources associated with that zone can be freed/collected. There's also a system zone for chrome code.

* GC arenas are allocated per zone. GC can collect a single zone (not a single compartment).

* Some GC things (strings, shapes, etc) are shared between compartments within a Zone.

* There are some special Zones: the atoms zone contains all atoms and symbols. The self-hosting zone/compartment contains self-hosted functions/scripts that can be lazily cloned into other compartments. Off-thread parsing uses its own zone/compartment that's later merged with the main-thread zone/compartment. 

ZoneGroup
---------
* ZoneGroups were added for cooperative scheduling but cooperative scheduling is not actually used right now and will probably be removed (bug 1434211, bug 1435689).

* A ZoneGroup contains zones that may reference each other. For instance, if window.open() is used, we may create a new zone for the new window, but because the two zones/windows can interact with each other they must belong to the same ZoneGroup. The system zone/ZoneGroup is special.

JSRuntime
---------
* A JSRuntime contains all (heap) state for a thread running JS. Every ZoneGroup/Zone belongs to a single runtime, except for the self-hosting zone and the set of permanent atoms (these are read-only and can be shared with the "parent runtime" to save memory).

* In the browser, the main thread, each web worker, etc has its own runtime.

JSContext
---------
* There's one JSContext per thread. This includes threads running JS, but also helper threads (helper threads are shared by all JSRuntimes in the process).

* With cooperative scheduling, there may be multiple contexts/threads per runtime that can execute JS (scheduled cooperatively). Once we remove cooperative scheduling, JSContext and JSRuntime will be related 1:1 again (except for the helper threads; they have a JSContext but are used by all runtimes in the process).

Comment 6

[Jason Orendorff [:jorendorff]]

Oh. We should have landed that comment and closed this.

Jan, please update comment 5 and let's get it into an [SMDOC] comment, maybe at the point in jsapi.h just above JS_NewContext.

Comment 7

[Jan de Mooij [:jandem]]

Stealing this back :)

Comment 8

[Jan de Mooij [:jandem]]

Attachment: Bug 1439466 - Add a comment explaining realms, compartments, zones, contexts, runtimes. r?jorendorff DONTBUILD

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/afe668c91201
Add a comment explaining realms, compartments, zones, contexts, runtimes. r=jorendorff DONTBUILD

Comment 10

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/afe668c91201