对于我使用 JVMTI 实现的探查器我想开始测量所有 Java 方法的执行时间。 JVMTI 提供以下事件:
方法入口方法退出
所以这很容易实现，但是我遇到了这个 note在 API 中:
Enabling method entry or exit events will significantly degrade performance on many platforms and is thus not advised for performance critical usage (such as profiling). Bytecode instrumentation should be used in these cases.
但是我的分析代理是 headless 工作的，这意味着收集的数据被序列化并通过套接字发送到显示结果的服务器应用程序。我应该如何使用字节码检测来实现这一点。我有点困惑如何从这里继续下去。有人可以向我解释一下，如果我必须改变策略或者我该如何解决这个问题吗？
最佳答案
我不了解 Sun JVM，但当您请求 MethodEntry/Exit 事件时，IBM JVM 会进入我们所说的 FullSpeedDebug 模式......FSD 会大大减慢执行速度。
正如您所说，您可以像我的分析器一样使用 BCI，但除非您对检测的方法有选择性，否则您也会发现速度变慢。例如，我的探查器在每个条目上插入一个 if(profiling) callProfilerHook() ，并且在所有对象创建的方法以及其他一些区域中的所有可能的导出上插入...这些额外的检查可能会使执行速度减慢 50% 以上...
至于如何BCI...我编写了自己的C库来做到这一点...技术上并不难(提示只需删除StackMapTable)，但我可能需要你一段时间..或者你可以使用ASM等。等。
最后...你的callBackHook会增加开销，并且在小方法上会导致报告的CPU/时钟时间毫无意义，除非你执行一些复杂的开销计算...即使你这样做，你的回调代码也会影响处理器L1缓存的形状，并且Java代码会变得效率较低，因为它的空间较小..
我的探查器基本上忽略了报告的时间，因为我以一种有趣的方式可视化执行情况...我希望了解所有代码的流程，事实上在大多数情况下正在运行什么代码(大多数 Java 项目不知道其应用程序中运行的数百万行第三方代码)
关于java - 使用 JVMTI 测量 Java 的执行时间，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5962923/