Garbage collector issues on spidermonkey… JS_AnchorPtr()?

Question

I've rolled my own javascript server side language called bondi. Just recently upgraded to the new spider monkey.

Now that JS enter local roots and leave local roots function is gone/useless from the 1.8.5 api, is it enough to just use anchor pointer(JS_AnchorPtr(varname)) at the end of your function calls to make sure the compiler isn't removing references to keep the garbage collector happy?

I've been testing it by removing all my references to JS_EnterLocalRootScope (see here) / Leave local root scope and adding JS_AnchorPtr() to the bottom of the script.

I looked up AnchorPoint function in the source code of spider monkey. Guess what... it does nothing. There's no doco for it either. I'm using it just so that I can get a mention in of those variables so the garbage collector doesn't kill them.

Answer 1

Well, blame seems to say that bug 519949 is recommending you use js::Anchor so that the conservative stack scanner will pick it up.

Note that the conservative scanner can find any GC thing that's on the stack or in registers, so the only really tricky case is where you use derived values when the "owning" GC thing may be dead, like so:

{
    JSString *str = GetMeSomeStringYo();
    const jschar *chars = str->chars();
    // Note, |str| is not "live" here, but the derived |chars| is!
    // The conservative stack scanner won't see |chars| and know
    // to keep |str| alive, so we should be anchoring |str|.
    DoSomethingThatCanCauseGC();
    return chars[0];
}

If you're using C the JS_AnchorPtr at the end of the functions should be enough. You are correct that the function has a nop implementation! The idea is that, so long as it's performing a call to a shared object symbol with the variable to keep alive as a parameter, the calling function will have to keep that value around in machine state in order to perform the do-nothing call. This is more sucky for perf than js::Anchor.

There's one potential trap in the unlikely case that you're statically linking against SpiderMonkey and have Link Time Optimization enabled: the cross-object call may be inlined with a null implementation, eliminating liveness of the variable, in which case the same GC hazards may pop back up.