虚拟机如何定义的“热点代码”

“ 上一篇文章我们说到Java的即时编译，与此同时分析了解释器和编译器，这一篇文章主要来看一下即时编译器如何定义热点代码去编译。”

通常而言热点数据我们都会放到一个"触手可及"的位置方便我们取放，就如同我们日常会将常用的物品放置在显眼的地方或者堆放在最上方，虚拟机中即时编译器也有这样的一个作用，将热点代码编译成本地机器码来提高运行效率。

01

—

编译对象和触发条件

在虚拟机中会被当作热点代码有两类：

被多次调用的方法 被多次执行的循环体

第一类很好理解：如果一个方法被调用的次数多了，那么方法体中的代码被执行的次数自然而然也是多。第二类指的是可能一个方法调用的次数并不多，但是由于方法体内部存在循环，其代码的执行次数并不少，这类代码同样会被认为是热点代码。对于第二类的情况虽然是因为循环体的原因被定义为热点代码，但是编译器仍然会以整个方法作为编译对象。这种编译方式因为编译发生在发放执行过程之中，因此形象地成为栈上替换(OSR编译，即方法栈帧还在栈上，方法就被替换了)

说到这里我们其实还没有明确一个问题，那就是代码到底执行多少次才能作为为即时编译器编译的条件呢？

判断一段代码是不是热点代码，是不是要触发即时编译，这样的行为称为热点探测(Hot Spot Detection)，其实进行热点探测并不一定要知道方法具体被调用了多少次，目前主流的热点探测判定方式有两种，分别如下：

1⃣️基于采样的热点探测(Sample Based Hot Spot Detection):采用这种方法的虚拟机会周期性的检查各个线程的栈顶(每个线程都会创建一个栈)，如果发现某个(或某些)方法经常出现在栈顶，那这个方法就是"热点方法"，基于采样的热点探测的好处是实现简单，高效，还可以很容易地获取方法调用关系，缺点是很难精确地确认一个方法的热度，容易收到线程阻塞或别的外界因素的影响而扰乱热点探测。 2⃣️基于计数器的热点探测(Counter Based Hot Spot Detection):采用这种方法的虚拟机会为每一个方法(甚至是代码块)建立计数器，统计方法的执行次数，如果执行次数超过一定的阀值就认为他是热点方法。这种统计方法实现起来麻烦一些，需要为每个方法建立并维护计数器，而且不能直接获取到方法的调用关系，但是它的统计结果相对来说更加严谨

HotSpot虚拟机中使用的是第二种方法，因此它为每个方法准备了两类计数器：方法调用计数器(Invocation Counter)和回边计数器(Back Edge Counter)

再确定虚拟机运行参数的前提下，这两个计数器都有一个确定的阀值，当计数器超过阀值的时候，就会触发JIT编译。

02

—

方法调用计数器

用于统计方法被调用的次数，它的默认阈值在 Client 模式下是 1500 次，在 Server 模式下是 10000 次，这个阈值可以通过虚拟机参数-XX：CompileThreshold来人为设定。

当一个方法被调用时，会先检查该方法是否存在被 JIT 编译过的版本，如果存在，则优先使用编译后的本地代码来执行。如果不存在已被编译过的版本，则将此方法的调用计数器值加 1，然后判断方法调用计数器与回边计数器值之和是否查过方法调用计数器的阈值。如果已超过阈值，那么将会向即时编译器提交一个该方法的代码编译请求。如果不做任何设置，执行引擎并不会同步等待编译请求完成，而是继续进入解释器按照解释方式执行字节码，直到提交的请求被编译器编译完成。当编译工作完成之后，这个方法调用入口地址就会被系统自动改成新的，下一次调用该方法时就会使用已编译的版本。整个 JIT 编译的交互过程如下图。

如果不做任何设置，方法调用计数器统计的并不是方法被调用的绝对次数，而是一个相对的执行频率，即一段时间之内方法被调用的次数。当超过一定的时间限度，如果方法的调用次数仍然不足以让它提交给即时编译器编译，那这个方法的调用计数器就会被减少一半，这个过程称为方法调用计数器热度的衰减，而这段时间就称为此方法统计的半衰周期。进行热度衰减的动作是在虚拟机进行垃圾收集时顺便进行的，可以使用虚拟机参数 -XX: -UseCounterDecay 来关闭热度衰减，让方法计数器统计方法调用的绝对次数，这样，只要系统运行时间足够长，绝大部分方法都会被编译成本地代码。另外，可以使用 -XX: CounterHalfLifeTime 参数设置半衰周期的时间，单位是秒。

03

—

回边计数器

它的作用是统计一个方法中循环体代码执行的次数，在字节码中遇到控制流向后跳转的指令称为 “回边”。 在Client 模式虚拟机的回边计数器的阈值为 13995，在Server 模式下的阈值为 10700。

当解释器遇到一条回边指令时，会先查找将要执行的代码片段是否有已经编译好的版本，如果有，它将会优先执行已编译的代码，否则就把回边计数器的值加 1，然后判断方法调用计数器与回边计数器之和是否超过回边计数器的阈值。当超过阈值的时候，将会提交一个 OSR 编译请求，并且把回边计数器的值降低一些，以便继续在解释器中执行循环，等待编译器输出编译结果，整个执行过程如下图。

与方法计数器不同，回边计数器没有计数热度衰减的过程，因此这个计数器统计的就是该方法循环执行的绝对次数。当计数器溢出的时候，它还会把方法计数器的值也调整到溢出状态，这样下次再进入该方法的时候就会执行标准编译过程。

在默认设置下，无论是方法调用产生的即时编译请求，还是 OSR 编译请求，虚拟机在代码编译器还未完成之前，都仍然将按照解释方式继续执行，而编译动作则在后台的编译线程中进行。用户可以通过参数 -XX: -BackgroundCompilation 来禁止后台编译，在禁止后台编译后，一旦达到 JIT 的编译条件，执行线程向虚拟机提交编译请求后将会一直等待，直到编译过程完成后再开始执行编译器输出的本地代码

03

—

Java 与 C/C++ 的编译器对比

Java 虚拟机的即时编译器与 C/C++ 的静态优化编译器相比，可能会由于下列这些原因而导致输出的本地代码有一些劣势。

第一，因为即时编译器运行占用的是用户程序的运行时间，具有很大的时间压力，它能提供的优化手段也严重受制于编译成本。如果编译速度不能达到要求，那用户将在启动程序或程序的某部分察觉到重大延迟，这点使得即时编译器不敢随便引入大规模的优化技术，而编译的时间成本在静态优化编译器中并不是主要的关注点。

第二，Java 语言是动态的类型安全语言，这就意味着需要由虚拟机来确保程序不会违反语言语义或访问非结构化内存。从实现层面上看，这就意味着虚拟机必须频繁地进行动态检查，如实例方法访问时检测空指针、数组元素访问时检测上下文范围、类型转换时检测继承关系等。对于这类程序代码没有明确写出的检查行为，尽管编译器会努力进行优化，但是总体上仍然要消耗不少的运行时间。

第三，Java 语言使用虚方法的频率却远远大于 C/C++ 语言，这意味着运行时对方法接收者进行多态选择的频率要远远大于 C/C++ 语言，也意味着即时编译在进行一些优化（如前面提到的方法内联）时的难度要远大于 C/C++ 的静态优化编译器。

第四，Java 语言是可以动态扩展的语言，运行时加载新的类可能改变程序类型的继承关系，这使得很多全局的优化都难以进行，因为编译器无法看见程序的全貌，许多全局的优化措施都只能以激进优化的方式来完成，编译器不得不时刻注意并随着类型的变化而在运行时撤销或重新进行一些优化。

第五，Java 语言中对象的内存分配都是堆上进行的，只有方法中的局部变量才能在栈上分配。而 C/C++ 的对象则有多种内存分配方式，既可能在堆上分配，又可能在栈上分配，如果可以在栈上分配线程私有的对象，将减轻内存回收的压力。另外，C/C++ 中主要由用户程序代码来回收分配的内存，这就不存在无用对象筛选的过程，因此效率上（仅指运行效率，排除了开发效率）也比垃圾收集机制要高。