JavaScript:SpiderMonkey:GC Futures

JS GC Futures

Tracking bug is bug 505308

Brain-dump of work items:

• Speed up allocator
  • Remove reserved objects and doubles stuff in the tracer bug 508140
  • Use one single GC heap chunk, avoiding frequent mmap and malloc calls bug 508707
• Speed up collector
  • Allocate short-enough strings from GC heap, not malloc heap bug 402614
  • Based on Gregor's stats consider making 32-byte and 64-byte JSObjects to cover most cases except large objects without any dslots bug 508357
  • Schedule GC based on memory pressure bug 506125
• Conservative stack scanning to avoid temp-value rooting overheads? bug 516832
• Go to beach

Compartments and per-compartment GC

Motivation

• More robust thread safety API
• Reduce GC pauses
• Minor performance win from eliminating object locking

Threading. In short, SM's support for sharing objects among threads has not gotten the maintenance attention it needs. It's accumulating bugs. At the same time, it is now widely acknowledged that shared-everything threads are a problematic programming model. Better ideas (like HTML5 Workers) are emerging. We need new JSAPI support for shared-nothing threads.

GC. At the same time our GC performance is not where we want it. There are still direct optimization opportunities. Beyond that, we want to be able to perform GC on a single browser tab, for shorter pause times when only one tab is active.

What these two things have in common is that they both involve dividing the JSRuntime's object graph into separate, mostly-isolated compartments, such that every object is in a compartment, and an ordinary object cannot have a direct reference to an object in a different compartment. (We will support special wrapper objects that provide transparent access to objects in other compartments.)

The changes we need to make for single-tab GC will simultaneously make it easier to add assertions enforcing the new rules about sharing objects across threads. Conveniently, in the browser, wrapper objects already exist in almost all the right places--it's a critical security boundary in the browser, and the wrappers impose various security policies.

Plans

These plans are limited to bugs that are on the critical path to per-tab GC, which we hope will dramatically reduce pause time.

Name	Size (weeks)	Assigned to (guess)
Benchmarks	1	gwagner
Benchmark automation	0.5	jorendorff
Compartments and wrappers API	2	jorendorff
Compartment assertions	1	jorendorff
GCSubheaps	2-3	gwagner
MT wrappers	3	jorendorff
Lock-free allocation and slot access	1	jorendorff
Compartmental GC	?	gwagner

Benchmarks — In bug 548388, Gregor is building a GC benchmark suite. We need a way to turn a crank and get GC performance numbers from that. sayrer should get mail when we make these numbers move. 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. (Automating this is bug 561486.)

Compartments and wrappers API — Add API for creating a global object and associating it with a compartment. Use it in Gecko everywhere we create a global. Add minimal API for a special kind of object that is allowed to hold a strong reference across compartments (a wrapper object). Use it in XPConnect for our security wrappers.

Compartment assertions — Add assertions that there are no direct references across compartments, both at API boundaries and within the engine. 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.

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.

Lock-free allocation and slot access — Remove locking from allocation paths. Remove scope locking everywhere. (bug 558866)

Compartmental GC — Support collecting garbage in one GCSubheap without walking the rest of the graph (bug 558861) and without stopping other threads.