The caller must ensure that the JSClass remains alive throughout the lifetime of the new object, including the garbage collection cycle that finally frees it. The usual way to do this is to make JSClasses global or static.

The option for new compartment (passed to JScompartment constructor). Added in SpiderMonkey 31

Description

JS_NewGlobalObject creates a new global object based on the specified class.

The new object has no parent. It initially has no prototype either, since it is typically the first object created; call JS_InitStandardClasses to create all the standard objects, including Object.prototype, and set the global object's prototype.

On success, JS_NewGlobalObject returns a pointer to the new object. Otherwise it returns NULL.

Debugger API Hook

During global creation, we fire notifications to callbacks registered via the Debugger API. These callbacks are arbitrary script, and can touch the global in arbitrary ways. When that happens, the global should not be in a half-baked state. But this creates a problem for consumers that need to set slots on the global to put it in a consistent state.

This API provides a way for consumers to set slots atomically (immediately after the global is created), before any debugger hooks are fired. It's unfortunately on the clunky side, but that's the way the cookie crumbles.

If callers have no additional state on the global to set up, they may pass FireOnNewGlobalHook to JS_NewGlobalObject, which causes that function to fire the hook as its final act before returning. Otherwise, callers should pass DontFireOnNewGlobalHook, which means that they are responsible for invoking JS_FireOnNewGlobalObject upon successfully creating the global. If an error occurs and the operation aborts, callers should skip firing the hook. But otherwise, callers must take care to fire the hook exactly once before compiling any script in the global's scope (we have assertions in place to enforce this). This lets us be sure that debugger clients never miss breakpoints.