Fixes to make JS GC truly exact:

- All jsvals for which JSVAL_IS_GCTHING evaluates to true must contain tagged
pointers into the GC heap -- therefore jsapi.c's JS_DefineConstDoubles cannot
"cheat" by tagging addresses of static jsdoubles to avoid js_NewNumberValue.

- Finalization is now interleaved with the Sweep phase, to avoid allocating
memory for finalization records while sweeping.  Instead, the JSRuntime holds a
preallocated JSGCThing vector (gcFinalVec) that the Sweep phase fills and
flushes via gc_finalize_phase, repeatedly.

This means that finalizers cannot allocate a new GC thing, an incompatible but
plausible change.  js_AllocGCThing asserts and then checks whether it is called
while rt->gcLevel is non-zero, and fails the allocation attempt if so.  But this
fixes bug 38942, where the old sweep-then-finalize with a sweep => malloc
dependency could lead to memory exhaustion.

- Instead of scanning whole stackPool arenas, which led to UMRs (bug 27924) and
sometimes to gross over-scanning that depended on the GC bounds-checking all
thing pointers against its heap, we scan exactly those stack slots in use:
  - arguments reachable from fp->argv;
  - variables reachable from fp->vars;
  - operands now reachable from fp->spbase, bounded above by the lesser of
    fp->sp or fp->spbase + fp->script->depth for an interpreted frame; if the
    latter, fp->sp has advanced logically above the operand budget, in order to
    call a native method, and all unused slots from fp->sp up to depth slots
    above fp->spbase must be set to JSVAL_VOID;
  - stack segments pushed when calling native methods, prefixed by JSStackHeader
    structs and linked from cx->stackSegments through each header.
The stack segment headers help the GC avoid scanning unused portions of the
stack: the generating pc slots running depth slots below fp->spbase, and slots
at the end of an arena that aren't sufficient to satisfy a contiguous allocation
for more args, vars, or operands.

- Exact GC means the stack pointer must remain above live operands until the
interpreter is done with them, so jsinterp.c got heavily whacked.  Instead of
POPs of various kinds followed by a PUSH for binary operators (e.g.), we use
FETCH and STORE macros that index by -1 and -2 from sp, and minimize adjustments
to sp.  When sp is homed to fp->sp, this allows js_DecompileValueGenerator to
find the value reliably, and if possible its generating pc.

- Finally, the O(n**2) growth rate of gc_find_flags has been fixed, using the
scheme sketched in bug 49816 and documented in a new major comment in jsgc.c.
Briefly, by allocating flags and things from one arena, we can align things on
1024-byte "thing page" boundaries, and use JSGCPageInfo headers in each page to
find a given thing's flags in O(1) time.

/be

js/src/jsopcode.h

@@ -198,14 +198,21 @@ js_DecompileFunction(JSPrinter *jp, JSFunction *fun);
 
 /*
  * Find the source expression that resulted in v, and return a new string
- * containing it.  Fall back on v's string conversion if we can't find the
- * bytecode that generated and pushed v on the operand stack.  Don't look
- * for v on the stack if checkStack is false.
+ * containing it.  Fall back on v's string conversion (fallback) if we can't
+ * find the bytecode that generated and pushed v on the operand stack.
+ *
+ * Search the current stack frame if spindex is JSDVG_SEARCH_STACK.  Don't
+ * look for v on the stack if spindex is JSDVG_IGNORE_STACK.  Otherwise,
+ * spindex is the negative index of v, measured from cx->fp->sp, or from a
+ * lower frame's sp if cx->fp is native.
  */
 extern JSString *
-js_DecompileValueGenerator(JSContext *cx, JSBool checkStack, jsval v,
+js_DecompileValueGenerator(JSContext *cx, intN spindex, jsval v,
 			   JSString *fallback);
 
+#define JSDVG_IGNORE_STACK      0
+#define JSDVG_SEARCH_STACK      1
+
 JS_END_EXTERN_C
 
 #endif /* jsopcode_h___ */