Spidermonkey 中的线程
我正在尝试在 SpiderMonkey 中启用线程调试转储，方法是 编辑 jsinterp.cpp 文件。基本上，我想做的事情 如下所示：
- 在 Interpret() 的主循环开始之前捕获 JSScript。
- 开一个单独的线程。
- 在该线程中，使用脚本调用 js_Disassemble 来获取 机器代码。
- 将机器代码写入文件。
尝试线程版本的原因只是为了性能 问题。如果我运行反汇编，一些插件会变得“无响应” 将输出写入同一线程中。我可以在一次中获得一些输出 线程，但速度太慢了。
我按照 https://developer.mozilla.org/en/Making_Cross-Thread_Calls_Using_Runnables 用于创建线程。但当我构建它时，我面临着11个“未解决的问题” 外部符号错误。”经过一番谷歌搜索后，我再次发现 通过 #define XPCOM_GLUE 1 设置 XPCOM_GLUE。但是，这次我是 面临新问题：“基类 nsRunnable 未定义”。我不能 找到解决方案。
任何帮助将不胜感激。 谢谢，
I am trying to enable a threaded debug dump in SpiderMonkey, by
editing the jsinterp.cpp file. Basically, the things I am trying to do
are as follows:
- Catch a JSScript before the main loop of Interpret() begins.
- Open a separate thread.
- In that thread, invoke js_Disassemble with the script to get the
machine code. - Write the machine code to a file.
The reason for trying a threaded version is simply for performance
issues. Some addons become "unresponsive" if I run the disassmeble and
write the output in the same thread. I can get some output in a single
thread but it's way too slow.
I followed the tutorial in https://developer.mozilla.org/en/Making_Cross-Thread_Calls_Using_Runnables
for creating threads. But when I built it, I faced 11 "unresolved
external symbol error." Again after some googling, I found out about
setting XPCOM_GLUE by #define XPCOM_GLUE 1. However, this time I am
facing a new problem: "base class nsRunnable not defined". I can't
find a solution for this.
Any help would be appreciated.
Thanks,
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
为此，您不能安全地使用单独的线程。垃圾收集可以在主线程上运行，并从您的下面收集
JSScript。然后进程就会崩溃。每次SpiderMonkey进入解释器时都会调用
js_Interpret，无论浏览器是运行You can't safely use a separate thread for this. Garbage collection could run on the main thread and collect the
JSScriptout from under you. Then the process would crash.js_Interpretis called every time SpiderMonkey enters the interpreter, whether the browser is running a<script>or just calling a function or anonclick=event listener. So you probably end up dumping the same scripts many times. Maybe that's why it's so slow. Consider dumping the bytecode at compile time instead.