Spidermonkey and Garbage Collection

Question

I am embedding Spidermonkey in my C++ application. I need to implementing some custom Javascript functions in native C++ that pass around a jsval. I need to guard the jsval against accidental garbage collection. Is it proper for me to do this:

(1) In an init routine:

static jsval vp; // a STATIC variable, value unknown
JSBool init((JSContext *cx, uintN argc, jsval *vp) {
   JS_AddValueRoot(cx,  &vp);
}

(2) In one c++ function implementing the Javascript function setter():

JSBool setter(JSContext *cx, uintN argc, jsval *vp) {
   ...
  vp=...;// set to some JSObject and hopefully makes any previous JSObject available for gc

}

(3) In a second C++ function call within the same compilation unit implementing the Javascript function getter():

JSBool getter(JSContext *cx, uintN argc, jsval *vp) {
  jsval somethingelse = vp; //directly retrieve the static value stored by setter()
  ....
}

My Javascript script uses the function calls like this:

init();
setter(...);
some_other_function_call_that_causes_gc();
getter();
setter(...);
some_other_function_call_that_causes_gc();
getter();
....
some_other_function_call_that_causes_gc();
setter(...);
some_other_function_call_that_causes_gc();
getter();

Note that I never call JS_RemoveRoot() since the static jsval vp is a permanent storage for my jsval passed between 2 function calls. And, I keep setting new values into the gc rooted static variable vp in my setter(), assuming any previouis JSObject stored in jsval will be available for garbage collection.

Are these proper ways to create gc rooted temporary variables that can be passed across function call? In particular, is the way my setter() replacing a previous JSObject a proper way to make an existing JSObject available for gc (i.e. no memory-leak/crash).

EDIT: The reason why I believe Garbage collection is an issue is that:

https://developer.mozilla.org/En/SpiderMonkey/JSAPI_User_Guide

Under Section JSAPI Concepts, Javascript Values:

a jsval by itself does not protect its referent from the garbage collector

https://developer.mozilla.org/en/SpiderMonkey_Garbage_Collection_Tips

Example 3 says "Root as you go" and shows how a jsval must be assigned to a root.

Answer 1

Referring to SpiderMonkey 17 and up

jsval or any other GC thing should be protected if there is a chance of triggering GC while the GC thing is in use. This is required even if jsval refers to an already protected storage. SpiderMonkey's GC is a moving GC.

Use RootedValue to protect stack based jsval and Heap<JS::Value> for heap based jsval
(jsval is the same as JS::Value). Use Handle<JS::Value> and MutableHandle<JS::Value> for arguments of functions.

Here is an excerpt from RootingAPI comments:

 * A moving GC may change the physical location of GC allocated things, even
 * when they are rooted, updating all pointers to the thing to refer to its new
 * location. The GC must therefore know about all live pointers to a thing,
 * not just one of them, in order to behave correctly.
 *
 * For a code fragment such as:
 *
 * JSObject *obj = NewObject(cx);
 * DoSomething(cx);
 * ... = obj->lastProperty();
 *
 * If |DoSomething()| can trigger a GC, the stack location of |obj| must be
 * rooted to ensure that the GC does not move the JSObject referred to by
 * |obj| without updating |obj|'s location itself. This rooting must happen
 * regardless of whether there are other roots which ensure that the object
 * itself will not be collected.
 *
 * If |DoSomething()| cannot trigger a GC, and the same holds for all other
 * calls made between |obj|'s definitions and its last uses, then no rooting
 * is required.
 *
 * SpiderMonkey can trigger a GC at almost any time and in ways that are not
 * always clear. For example, the following innocuous-looking actions can
 * cause a GC: allocation of any new GC thing; JSObject::hasProperty;
 * JS_ReportError and friends; and ToNumber, among many others. The following
 * dangerous-looking actions cannot trigger a GC: js_malloc, cx->malloc_,
 * rt->malloc_, and friends and JS_ReportOutOfMemory.

Answer 2

There is no need to add a root for something like a jsval. You simply need to maintain a reference to the value in your script. SpiderMonkey GC is refrence count based, therefore your jsvals will not dissapear as long as they are referred to in the current scope:

var x = 5;

callNativeFun(x);

function foo() { throw true; }

print(nativeFunRef());

//script ends here. X and FOO will be garbage collected as will callNativeFun and nativeFunRef js function signatures.

In the above code example both x and foo are held referent by the global object.

As long as the jsval pointer content is defined in the script it will never reach GC. Make sure your binary code never uses the value after its life is over; that is when you are done with it in the script and call delete on it or set its value to undefined by value or proxy of scope termination. If you forsee any of these negative interactions you should be setting a GC root on that jsval.