Garbage collector issues on spidermonkey… JS_AnchorPtr()?

后端 未结 1 563
时光说笑
时光说笑 2021-01-21 08:11

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 fu

相关标签:
1条回答
  • 2021-01-21 08:44

    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.

    0 讨论(0)
提交回复
热议问题