Sfink/Contexts and Compartments: Difference between revisions

This is my attempt to make sense of a couple of fundamental SpiderMonkey data structures, compartments and contexts. I am far from an expert, but mrbkap (who *is* the expert) has read through this and pointed out only one glaring mistake, since fixed. So it should be more or less correct now.

A JSContext (from here on, just ''context'') represents the execution of JS code. A context contains a JS stack and is associated with a runtime. A thread may use multiple contexts, but a given context will only execute on a single thread at a time.

A JSCompartment (''compartment'') is a memory space that objects and other garbage-collected things (''GCthings'') are stored within.

A context is associated with a single compartment at all times (not necessarily always the same one, but only ever one at a time). The context is often said to be "running inside" that compartment. Any object created with that context will be physically stored within the context's current compartment. Just about any GCthing read or touched by that context should also be within that same compartment.

To access data in another compartment, a context must first "enter" that other compartment. This is termed a "cross-compartment call" -- remember, contexts are control, so changing a context's compartment is only meaningful if you're going to run code. The context will enter another compartment, do some stuff, then return, at which time it'll exit

back to the original compartment. (The APIs allow you to change to a different compartment and never change back, but that's almost certainly a bug and will quickly trigger an assertion in a debug build the first time you touch an object in a compartment that differs from your context's compartment.)

When a context is not running code -- as in, its JS stack is empty and it is not in a request -- then it isn't really associated with any compartment at all. In the future, starting a request and entering an initial compartment will become the same action. Also, a context is only ever running on one thread at a time. '''Update:''' or perhaps we'll eliminate contexts altogether and just map from a thread to the relevant data.

In implementation terms, a context has a field (cx->compartment) that gives the current compartment. Contexts also maintain a default scope object (cx->globalObject) that

is required to always be within the same compartment, and a "pending exception" object which, if set, will also be in the same compartment. Any object created using a context will be created inside the context's current compartment, and the object's scope chain will be initialized to a scope object within that same compartment. (That scope object ''might'' be cx->globalObject, but really that's just the ultimate fallback. Usually the scope object will be found via the stack instead.)

 

 

 

 

Anything within a single compartment can freely and directly access anything else in that same compartment. No locking or wrappers are necessary (or possible). The overall model is thus a partitioning of all (garbage collectible) data into separate compartments, with controlled access from one compartment to another but lockless, direct access between objects within a compartment. Cross-compartment access is handled via "wrappers", the topic of the next section.

decide how to divide up data into different compartments, and what behavior