Set correct GC parameters and max memory usage
Submitted by Havoc Pennington
Link to original bug (#562575)
Description
The trick to this bug is to define "correct." Our current code is:
JS_NewRuntime(1024*1024 /* max bytes */);
This leads to a lot of catastrophic out-of-memory errors. (Our app may be leaking, but it's not hard to imagine hitting this limit without leaking.)
If I'm looking in the right place, mozilla does this:
const uint32 gGCSize = 32L * 1024L * 1024L; /* pref? */
mRuntime = JS_NewRuntime(gGCSize);
if(!mRuntime)
return NS_ERROR_OUT_OF_MEMORY;
// Unconstrain the runtime's threshold on nominal heap size, to avoid
// triggering GC too often if operating continuously near an arbitrary
// finite threshold (0xffffffff is infinity for uint32 parameters).
// This leaves the maximum-JS_malloc-bytes threshold still in effect
// to cause period, and we hope hygienic, last-ditch GCs from within
// the GC's allocator.
JS_SetGCParameter(mRuntime, JSGC_MAX_BYTES, 0xffffffff);
I can't say I really understand the comment in the mozilla code.
There are two GC parameters: JSGC_MAX_BYTES and JSGC_MAX_MALLOC_BYTES. The arg to JS_NewRuntime() sets both of them at once.
There are no docs I can find except the comments in jsapi.h:
typedef enum JSGCParamKey {
/* Maximum nominal heap before last ditch GC. */
JSGC_MAX_BYTES = 0,
/* Number of JS_malloc bytes before last ditch GC. */
JSGC_MAX_MALLOC_BYTES = 1,
/* Hoard stackPools for this long, in ms, default is 30 seconds. */
JSGC_STACKPOOL_LIFESPAN = 2
} JSGCParamKey;
But for me this just raises questions like "what does 'nominal' mean here?" and "when is JS_malloc used vs. something else?"
Another factor, I would think triggering GC at some number of bytes SpiderMonkey knows about is almost nonsensical, because in a gjs environment each JS object is pointing to a potentially much larger C object ... perhaps we want to manually trigger GC based on something other than how much memory SpiderMonkey thinks is allocated. Though I'm not sure what it would be based on. It would seem xpcom has this issue also so perhaps there's a solution, or perhaps it just doesn't matter.