JVM如何决定JIT编译方法（将方法归类为“热”）？

Question

我已经使用过-XX:+PrintCompilation，并且我知道JIT编译器的基本技术以及为什么使用JIT编译。

但是我仍然没有找到JVM如何决定JIT编译方法的方法，即“何时到了JIT编译方法的正确时间”。

我假设每个方法都开始被解释，并且只要不将其归类为“热方法”，就不会编译吗？我脑海里有些东西我读到，当一个方法执行至少10.000次（解释该方法10.000次后，将被编译）时，该方法被视为“热”，但我必须承认不知道这个或我在哪里读过。

所以总结一下我的问题：

（1）是否对每种方法都进行了解释，只要它没有被归类为“热”方法（因此已经被编译），或者即使不是“热”方法也有理由被编译吗？

（2）JVM如何将方法分为“非热”和“热”方法？执行次数？还要别的吗？

（3）如果“热”方法有某些阈值（如执行次数），是否有Java标志（-XX:...）设置该阈值？

Answer 1

HotSpot编译策略相当复杂，尤其是对于分层编译而言，它在Java 8中是默认启用的。它既不是执行次数，也不是CompileThreshold参数。最佳解释（显然是唯一合理的解释）可以在HotSpot源代码中找到，请参阅advancedThresholdPolicy.hpp。我将总结此高级编译策略的要点：执行从第0层（解释器）开始。编译的主要触发因素是方法调用计数器i;后柜台b。向后分支通常表示代码中的循环。每次计数器达到一定的频率值（TierXInvokeNotifyFreqLog，TierXBackedgeNotifyFreqLog），编译政策被称为决定下一步与当前正在运行的方法做什么。取决于的值i，b而C1和C2的编译器线程的当前负载，可以决定继续在解释器中执行；开始分析翻译；在第3层使用C1编译方法，并提供进一步重新编译所需的完整配置文件数据；C1在第2层的编译方法，没有概要文件，但有可能重新编译（不太可能）；最后在第1层使用C1编译方法，没有配置文件或计数器（也是不太可能）。这里的关键参数是TierXInvocationThreshold和TierXBackEdgeThreshold。可以根据编译队列的长度为给定方法动态调整阈值。编译队列不是FIFO，而是优先级队列。具有概要数据（第3层）的C1编译代码的行为类似，不同之处在于切换到下一个级别（C2，第4层）的阈值要大得多。例如，解释的方法可以在调用约200次后在第3层进行编译，而C1编译的方法则需要在调用5000次以上后在第4层进行重新编译。特殊策略用于方法内联。即使它们不是“热”的，它们也可以内联到调用者中。只有频繁调用（）时InlineFrequencyRatio，才可以内联更大的方法InlineFrequencyCount。

Answer 2

控制此的主要参数是 -XX:CompileThreshold=10000Java 8热点现在默认使用分层编译，默认情况下使用从1级到4级的多个编译阶段。我相信1并不是最优化的。级别3为C1（基于客户端客户端），级别4为C2（基于服务器编译器）这意味着可以比您预期的更早进行一些优化，并且可以在达到10K阈值后继续进行优化。我看到的最高级别是转义分析，在一百万次调用后消除了StringBuilder。注意：循环多次会触发编译器。例如，一个10K次的循环就足够了。1）在方法被认为足够热之前，将对其进行解释。但是，某些JVM（例如Azul Zing）可以在启动时编译方法，并且您可以强制Hotspot JVM通过内部API编译方法。Java 9可能还具有AOT（提前）编译器，但AFAIK仍在研究中2）调用次数或迭代次数。3）是-XX:CompileThreshold=的。

Answer 3

您还有其他资料可供我阅读吗？我知道C1和C2，但我还没有听说过1-4级编译（Interpeter，C1，C2为3级）。而且，您基本上可以说，在下方可以认为一种方法很热门CompilerThreshold。那么这个门槛是多少？我是否可以期待某个方法在被称为“ Times ”时最晚被认为是热门方法CompilerThreshold？