JVM如何决定JIT编译方法(将方法分类为“热”)? [英] How does the JVM decided to JIT-compile a method (categorize a method as "hot")?

查看:186
本文介绍了JVM如何决定JIT编译方法(将方法分类为“热”)?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我已经使用 -XX:+ PrintCompilation ,我知道JIT编译器的基本技术以及使用JIT编译的原因。

I already worked with -XX:+PrintCompilation, and I know the basic techniques of the JIT-compiler and why JIT-compilation is used.

然而,我仍然没有发现JVM如何决定JIT编译方法,即正确的时间来到JIT编译方法。

Yet I still have not found out how the JVM decides to JIT-compile a method, i.e. "when the right time has come to JIT-compile a method".

我是否正确地假设每个方法都开始被解释,只要它没有被归类为热方法,它就不会被编译?我有一些东西在脑后,我读到一个方法被认为是热,当它被执行至少10.000次(解释方法10.000次后,它将被编译),但我不得不承认我是不确定这个或我在哪里读过这个。

Am I right in the assumption that every method starts being interpreted, and as long as it is not categorized as "hot method" it will not be compiled? I have something in the back of my head that I read that a method is considered "hot" when it was executed at least 10.000 times (after interpreting the method 10.000 times, it will be compiled), but I have to admit that I am not sure about this or where I've read this.

所以总结一下我的问题:

So to sum up my question:

( 1)每个方法是否被解释,只要它没有被归类为热方法(因此已被编译)或者是否有理由让方法被编译即使它们不是热 ?

(1) Is every method interpreted as long as it not has been categorized as "hot" method (and therefore has been compiled) or are there reasons for methods to get compiled even if they are not "hot"?

(2)JVM如何将方法分类为非热和热方法?执行次数?还有什么吗?

(2) How does the JVM categorize methods into "non-hot" and "hot" methods? Number of execution? Anything else?

(3)如果热方法有某些阈值(如执行次数),是否有Java标志( - XX:... )设置此阈值?

(3) If there are certain thresholds (like number of executions) for "hot" methods, are there Java flags (-XX:...) to set this thresholds?

推荐答案

HotSpot编译策略相当复杂,特别是对于分层编译,它在Java 8中默认启用。它既不是多个执行,也不是 CompileThreshold 参数。

HotSpot compilation policy is rather complex, especially for Tiered Compilation, which is on by default in Java 8. It's neither a number of executions, nor a matter of CompileThreshold parameter.

最好的解释(显然,唯一的合理解释)可以在HotSpot源代码中找到,参见 advancedThresholdPolicy.hpp

The best explanation (apparently, the only reasonable explanation) can be found in HotSpot sources, see advancedThresholdPolicy.hpp.

我将总结这个高级编译策略的要点:

I'll summarize the main points of this advanced compilation policy:


  • 执行从第0层开始(解释器)。

  • 编译的主要触发器是

  • Execution starts at tier 0 (interpreter).
  • The main triggers for compilation are

  1. 方法i nvocation counter i ;

  2. backupge counter b 。后向分支通常表示代码中的循环。

  1. method invocation counter i;
  2. backedge counter b. Backward branches typically denote a loop in the code.


  • 每次计数器达到特定频率值( TierXInvokeNotifyFreqLog TierXBackedgeNotifyFreqLog ),调用编译策略来决定当前运行的方法下一步该做什么。根据 i b 的值以及C1和C2编译器线程的当前加载,可以决定

  • Every time counters reach certain frequency value (TierXInvokeNotifyFreqLog, TierXBackedgeNotifyFreqLog), a compilation policy is called to decide what to do next with currently running method. Depending on the values of i, b and current load of C1 and C2 compiler threads it can be decided to


    • 继续执行翻译;

    • 在翻译中开始分析;

    • 在第3层使用C1编译方法,并进行进一步重新编译所需的完整配置文件数据;

    • 在第2层使用C1但没有配置文件但有可能重新编译(不太可能)的编译方法;

    • 最后在第1层使用C1编译方法,没有配置文件或计数器(也不太可能)。

    • continue execution in interpreter;
    • start profiling in interpreter;
    • compile method with C1 at tier 3 with full profile data required for futher recompilation;
    • compile method with C1 at tier 2 with no profile but with possibility to recompile (unlikely);
    • finally compile method with C1 at tier 1 with no profile or counters (also unlikely).

    这里的关键参数是 TierXInvocationThreshold TierXBackEdgeThreshold 。根据编译队列的长度,可以为给定方法动态调整阈值。

    Key parameters here are TierXInvocationThreshold and TierXBackEdgeThreshold. Thresholds can be dynamically adjusted for a given method depending on the length of compilation queue.

    编译队列不是FIFO,而是优先级队列。

    Compilation queue is not FIFO, but rather a priority queue.

    具有配置文件数据(第3层)的C1编译代码的行为类似,只是切换到下一级别(C2,第4层)的阈值要大得多。例如。在大约200次调用之后,可以在第3层编译解释的方法,而在5000次调用之后,C1编译的方法可以在第4层进行重新编译。

    C1-compiled code with profile data (tier 3) behave similarly, except that thresholds for switching to the next level (C2, tier 4) are much bigger. E.g. an interpreted method can be compiled at tier 3 after about 200 invocations, while C1-compiled method is subject for recompilation at tier 4 after 5000+ invocations.

    这篇关于JVM如何决定JIT编译方法(将方法分类为“热”)?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

  • 查看全文
    登录 关闭
    扫码关注1秒登录
    发送“验证码”获取 | 15天全站免登陆