如何使用 JNI+JVMTI 捕获 JIT 的去优化事件，例如“unstable_if”

Question

我真的很想知道如何捕捉 JIT 的去优化事件。
今天，我读到了 Andrei Pangin 的精彩回答当忙碌的 Java 线程绑定到物理核心时，是否会因为到达代码中的新分支而发生上下文切换？并再次考虑。

我想用 JNI+JVMTI 捕捉 JIT 的去优化事件，如“unstable_if、class_check 等”，然后向我的监控系统或其他任何东西发送警报。

是否可以？它对 JVM 的性能有什么影响？

Answer 1

不常见的陷阱和去优化是 HotSpot 的实现细节。您不会在像 JVM TI（它是为通用虚拟机而设计的，而不仅仅是 HotSpot）这样的标准接口中找到它们。

正如我之前的回答所建议的，诊断反优化的一种可能方法是添加-XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation选项并<uncommon_trap>在编译日志中查找。

另一种方法是使用async-profiler跟踪去优化事件。
为此，请使用-e Deoptimization::uncommon_trap_inner.
如果使用jfr输出格式，这将显示 Java 代码中发生反优化的位置，以及时间戳。

从 JDK 14 开始，Flight Recorder ( JDK-8216041 )也会本地报告去优化事件。在 JMC 中使用事件浏览器，您可能会发现所有不常见的陷阱，包括方法名称、字节码索引、去优化原因等。

以上所有方法的开销都足够小。在生产中使用 async-profiler 通常没有问题；如果录制设置不是多余的，JFR 也很好。

但是，除了非常特殊的情况外，分析去优化并没有太大用处。这对于典型的 Java 应用程序多次重新编译方法来说是绝对正常的，只要 JVM 在运行时了解更多有关应用程序的信息。听起来可能很奇怪，但不常见的陷阱是投机优化的常见技术:) 正如您在上面的图片中看到的，即使是基本的方法HashMap.put也可能会导致反优化，这很好。