Zones

[Bill McCloskey]

Hi everyone,

Zones landed over the weekend and it looks like it's going to stick this
time. I saw a few questions this morning on IRC about what the new
invariants are, so I wrote a comment explaining things as best I could
(bug 852229). I'm attaching it in the email. Any input would be welcome.

/*
* A zone is a collection of compartments. Every compartment belongs to
exactly
* one zone. In Firefox, there is roughly one zone per tab along with a
system
* zone for everything else. Zones mainly serve as boundaries for garbage
* collection. Unlike compartments, they have no special security
properties.
*
* Every GC thing belongs to exactly one zone. GC things from the same
zone but
* different compartments can share an arena (4k page). GC things from
different
* zones cannot be stored in the same arena. The garbage collector is
capable of
* collecting one zone at a time; it cannot collect at the granularity of
* compartments.
*
* GC things are tied to zones and compartments as follows:
*
* - JSObjects belong to a compartment and cannot be shared between
* compartments. If an object needs to point to a JSObject in a different
* compartment, regardless of zone, it must go through a
cross-compartment
* wrapper. Each compartment keeps track of its outgoing wrappers in
a table.
*
* - JSStrings do not belong to any particular compartment, but they do
belong
* to a zone. Thus, two different compartments in the same zone can
point to a
* JSString. When a string needs to be wrapped, we copy it if it's in a
* different zone and do nothing if it's in the same zone. Thus,
transferring
* strings within a zone is very efficient.
*
* - Shapes and base shapes belong to a compartment and cannot be
shared between
* compartments. A base shape holds a pointer to its compartment.
Shapes find
* their compartment via their base shape. JSObjects find their
compartment
* via their shape.
*
* - Scripts are also compartment-local and cannot be shared. A script
points to
* its compartment.
*
* - Type objects and IonCode objects belong to a compartment and cannot be
* shared. However, there is no mechanism to obtain their compartments.
*
* A zone remains alive as long as any GC things in the zone are alive. A
* compartment remains alive as long as any JSObjects, scripts, shapes,
or base
* shapes within it are alive.
*
* We always guarantee that a zone has at least one live compartment by
refusing
* to delete the last compartment in a live zone. (This could happen, for
* example, if the conservative scanner marks a string in an otherwise dead
* zone.)
*/

-Bill

[Wes Garland]

So, zones are roughly analogous to a JSRuntime from the embedder's POV?

Wes

> _______________________________________________
> dev-tech-js-engine-internals mailing list
> dev-tech-js-en...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals



--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102

[Bill McCloskey]

On 03/18/2013 11:46 AM, Wes Garland wrote:
> So, zones are roughly analogous to a JSRuntime from the embedder's POV?

When you call JS_NewGlobalObject, you now tell it what zone to put the
compartment into. By default, every global gets its own zone. However,
you could choose to put everything in the system zone and then you'll
mostly get what you describe (except that the atoms compartment will
still be in a separate zone).

If you weren't using per-compartment GC before, then it makes sense to
put everything in the same zone.

-Bill