本文介绍了垃圾收集器问题spidermonkey .... JS_AnchorPtr()?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我推出了自己的javascript服务器端语言bondi。刚刚升级到新的蜘蛛猴。

现在JS输入本地根目录并且离开本地根功能从1.8.5 api中消失/无用了,是否足够只需在函数调用结束时使用锚点指针( JS_AnchorPtr(varname))来确保编译器不移除引用以保持垃圾回收器快乐?



我一直在通过删除所有对JS_EnterLocalRootScope的引用来测试它()
/保留本地root作用域并在脚本底部添加 JS_AnchorPtr()



我在蜘蛛猴的源代码中查找了AnchorPoint函数。猜猜......什么都不做。对此也没有任何要求。我正在使用它,以便我可以提及这些变量,所以垃圾收集器不会杀死它们。

解决方案

好吧,责怪似乎说建议你使用js: :锚点,使保守的堆栈扫描器将它拿起来。



请注意,保守的扫描器可以找到堆栈中或寄存器中的任何GC东西,所以唯一真正的棘手的情况是,当拥有GC事件可能已经死亡时,你可以使用派生值,如下所示:

  {
JSString * str = GetMeSomeStringYo();
const jschar * chars = str-> chars();
//注意,| str |在这里不是活的,而是派生出来的| chars |是!
//保守的堆栈扫描器不会看到|字符|并知道
//保持| str |活着,所以我们应该锚定| str |。
DoSomethingThatCanCauseGC();
返回字符[0];



$ b $ p
$ b如果你使用C,函数末尾的JS_AnchorPtr应该是足够。你是正确的,该函数有一个nop实现!这个想法是,只要它正在执行一个调用共享对象符号并使变量保持为参数的状态,调用函数就会将该值保持机器状态,以便执行无所作为的呼叫。对于perf而言,这比js :: Anchor更加糟糕。



有一个潜在的陷阱,你可能会静态链接到SpiderMonkey并启用链接时间优化:交叉对象调用可以用null实现内联,消除变量的活性,在这种情况下,相同的GC危害可能会弹出。

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.

解决方案

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.

这篇关于垃圾收集器问题spidermonkey .... JS_AnchorPtr()?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

09-18 06:52