如何使用D8获得WebAssembly的功能优化状态？
在JavaScript ％getOptimizationStatus函数中存在，它返回编译管道中功能的当前状态。 另外，- trace-opt/ - trace-deopt/ - Trace-Baseline与JavaScript源代码正常工作。
webassebmly优化状态，另一方面似乎不可能使用这些技术进行研究。我如何看到WebAssembly功能成功地通过了升降机/涡轮汇款？
In JavaScript %GetOptimizationStatus function exists, which returns the current status of a function in a compilation pipeline.
Also, --trace-opt/--trace-deopt/--trace-baseline work fine with JavaScript source code.
WebAssebmly optimization statuses, on the other side seem to be impossible to research with those techniques. How can I see that the WebAssembly function successfully passed Liftoff/Turbofan?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
有
％isliftoffunction（自然仅适用于JS可见的函数，即导出的功能），并且有- trace-wasm-compilation-times。通常，当开发人员（1）需要它时，追踪功能将建立，并且（2）假设将来将足够有用，可以实际降落代码，而不是仅在几个
中进行黑客攻击。 printfs在本地，然后在解决了手头问题时丢弃它们。 WASM执行模型非常简单（目前），以至于为其构建跟踪并不需要太多。 （而且它曾经更简单，直到几个月前我们打开动态层。）截至今天（2022-05-29，这部分可能不会很好地老化），在默认配置中：
There's
%IsLiftoffFunction(which naturally only works for functions visible to JS, i.e. exported functions), and there's--trace-wasm-compilation-times.Generally, tracing functionality gets built when a developer (1) has a need for it, and (2) assumes that it'll be sufficiently useful in the future to actually land the code, as opposed to just hacking in a few
printfslocally and then discarding them when the issue at hand has been solved. The Wasm execution model is so simple (for now) that there hasn't been much need to build tracing for it. (And it used to be even simpler, until we turned on dynamic tiering a few months ago.)As of today (2022-05-29, this part probably won't age very well), in the default configuration: