52
edits
JavaScript:SpiderMonkey:GC Futures: Difference between revisions
JavaScript:SpiderMonkey:GC Futures (view source)
Revision as of 21:59, 27 April 2021
, 27 April 2021Mark as Outdated
(→Plans) |
(Mark as Outdated) |
||
| (13 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
{{OutdatedSpiderMonkey}} | |||
== JS GC Futures == | == JS GC Futures == | ||
| Line 54: | Line 56: | ||
|- | |- | ||
| Compartments and wrappers API | | Compartments and wrappers API | ||
| | | 1 | ||
| jorendorff | | jorendorff | ||
|- | |- | ||
| | | Compartmentalize Gecko | ||
| | | 3 | ||
| jorendorff | | jorendorff | ||
|- | |- | ||
| Line 67: | Line 69: | ||
| MT wrappers | | MT wrappers | ||
| 3 | | 3 | ||
| | | gal | ||
|- | |- | ||
| Lock-free allocation and slot access | | Lock-free allocation and slot access | ||
| 1 | | 1 | ||
| | | gal | ||
|- | |- | ||
| Compartmental GC | | Compartmental GC | ||
| Line 78: | Line 80: | ||
|} | |} | ||
'''Benchmarks''' — | '''Benchmarks''' — Gregor is building a GC benchmark suite. We need it checked in. ({{bug|548388}}) | ||
''' | '''Benchmark automation''' — We need to be able to turn a crank and get GC performance numbers. Talos needs to run this automatically. This means we need to be able to measure GC performance in opt builds. Total time spent in GC and max pause time are cheap enough to collect. ({{bug|561486}}) | ||
''' | '''Compartments and wrappers API''' — Add API for creating a global object and associating it with a compartment. Add minimal API for a special kind of object that is allowed to hold a strong reference across compartments (a wrapper object). Add assertions within the engine that there are no direct references across compartments. Add assertions at API boundaries that all the gc-things provided as arguments come from the same compartment. ({{bug|563099}}) | ||
'''Compartmentalize Gecko''' — Use the compartment API to divide up Gecko so that objects with different principals are always in different compartments. Use the wrapper API in XPConnect for our security wrappers. Fix what breaks. In particular, wrappers and the structured clone algorithm will need to copy strings and doubles instead of passing them freely from one compartment to another. ({{bug|563106}}) | |||
'''GCSubheaps''' — Factor GC-related code into a class, js::GCHeap ({{bug|556324}}). Carve out a second class, GCSubheap, so that a single GCHeap can have several GCSubheaps, each of which handles its own set of VM pages from which individual GC things may be allocated. Give each compartment its own GCSubheap. Allocate every object, double, and string from the GCSubheap for the compartment where it will live. | '''GCSubheaps''' — Factor GC-related code into a class, js::GCHeap ({{bug|556324}}). Carve out a second class, GCSubheap, so that a single GCHeap can have several GCSubheaps, each of which handles its own set of VM pages from which individual GC things may be allocated. Give each compartment its own GCSubheap. Allocate every object, double, and string from the GCSubheap for the compartment where it will live. | ||
'''MT wrappers''' — Implement an automatically-spreading membrane of proxy objects that allow one thread to access objects from another compartment that is running in another thread. There is some risk here because it's unclear how this should work regarding objects on the scope chain (global objects, Call and Block objects). See {{bug|558866}} comments 1-4. | '''MT wrappers''' — Implement an automatically-spreading membrane of proxy objects that allow one thread to access objects from another compartment that is running in another thread. There is some risk here because it's unclear how this should work regarding objects on the scope chain (global objects, Call and Block objects). See {{bug|558866}} comments 1-4. See also {{bug|566951}}, which has a prototype patch that addresses the scope chain issue. | ||
'''Lock-free allocation and slot access''' — Remove locking from allocation paths. Remove scope locking everywhere. ({{bug|558866}}) | '''Lock-free allocation and slot access''' — Remove locking from allocation paths. Remove scope locking everywhere. ({{bug|558866}}) | ||
| Line 139: | Line 143: | ||
This won't work because I plan to implement MT objects using custom JSObjectOps. So JS_AUTO_MT_OBJECTS would make all objects non-native, which would break major engine invariants (e.g. the global object must be native). | This won't work because I plan to implement MT objects using custom JSObjectOps. So JS_AUTO_MT_OBJECTS would make all objects non-native, which would break major engine invariants (e.g. the global object must be native). | ||
--> | --> | ||
=== Compartments and wrappers - API === | |||
Each runtime has a ''default compartment'' which contains interned strings, the empty string, +Inf, -Inf, NaN—and, in non-compartment-aware embeddings, everything else. | |||
Each context has a ''current compartment'', initially the default compartment, and normally the compartment of JS_GetScopeChain(cx). So, for example, <code>js_Atomize(cx, name, strlen(name), 0)</code> allocates the new string from <code>cx->currentCompartment()</code>. | |||
A tricky consequence of this is that in an API call <code>JS_SetProperty(cx, obj, name, vp)</code>, obj must be in <code>cx->currentCompartment()</code>, because <code>JS_SetProperty</code> calls <code>js_Atomize</code> to create the property id. Otherwise obj could end up with property ids that reside in <code>cx->currentCompartment()</code> rather than its own compartment: a violation of the rules that will lead to a crash in GC. | |||
When does a context's current compartment need to change? Only when setting up a new compartment and when calling across compartment boundaries. The latter always happens in wrapper code. So this will be rare and we can require an API call and fall off trace when it happens. | |||
JSCompartment * | |||
JS_GetDefaultCompartment(JSRuntime *rt); | |||
JSCompartment * | |||
JS_NewCompartment(JSRuntime *rt, JSPrincipals *principals); | |||
JSCompartment * | |||
JS_GetCurrentCompartment(JSContext *cx); | |||
void | |||
JS_SetCurrentCompartment(JSContext *cx, JSCompartment *compartment); | |||
All existing APIs could just assert that cx->currentCompartment() agrees with all the arguments that happen to be gc-things. The precise rule is: each gc-thing passed in must either be in <code>cx->currentCompartment()</code> or be a string or double in <code>cx->runtime->defaultCompartment</code>. | |||
'''GC roots''' will be per-compartment. This means <code>JS_AddGCRootRT</code> will add a root to the default compartment. This behavior is a bit unexpected. To help embeddings get this right, GC should assert that each gc thing pointed to by a root is in the expected compartment. | |||
'''API functions related to the GC heap.''' Several API functions do something that involves the GC heap: <code>JS_GC</code> and friends; <code>JS_SetGCCallback</code>; <code>JS_SetGCParameter</code>; <code>JS_TraceChildren</code> and friends; <code>JS_DumpHeap</code>; <code>JS_SetGCZeal</code>. These will need to have a mode for collecting/walking the entire heap and a separate mode where they apply to just one compartment. TBD. | |||
'''Wrapper API.''' Since the cross-compartment reference from a wrapper to the wrappee is so special, we will need API for it. TBD. | |||
== Emerging Invariants == | |||
This section describes invariants and rules which have emerged during initial development of the conservative GC and the compartments code. They are not likely to change, but still may. | |||
* The C stack is not scanned for GC roots when there are no contexts (suspended or otherwise) in requests on a given thread | |||
* When doing a single-compartment GC, only the current thread's stack is scanned (unless there are no contexts in requests on that thread) | |||
* A context's compartment is equal to JS_GetScopeChain(cx)->getCompartment. A NULL scope chain indicates the default compartment. | |||
* Corollary: All non-default compartments have at least a global object. | |||
* Only one thread per compartment may be in a request at any given time | |||