笔记-Java基础之Hotspot虚拟机编译对象与触发条件

    程序在运行过程中会被即时编译器编译的“热点代码”有两类，既：

    1.被多次调用的方法。

    2.被多次执行的循环体。

    前者很好理解，一个方法被调用得多了，方法体内代码执行的次数自然就多了，它成为“热点代码”是理所当然的。而后者则是为了解决一个方法只被调用一次或少数的几次，但是方法体内部存在循环次数较多的循环体的问题，这样循环体的代码也被重复执行多次，因此这些代码也应该认为是“热点代码”。

    对于第一种情况，由于是由方法调用触发的编译，因此编译器理所当然地会以整个方法作为编译对象，这种编译也是虚拟机中标准的JIT编译方式。而对于后一种情况，尽管编译动作是由正循环体触发的，但编译器依然会以整个方法（而不是单独的循环体）作为编译对象。这种编译方式因为编译发生在方法执行过程中，因此形象地称之为栈上替换（On Stack Replacement，简称OSR编译，既方法栈帧还在栈上，方法就被替换了）。

    “多次调用”那到底多少次才算“多次”呢？还有就是，虚拟机如何统计一个方法或一段代码被执行过多少次呢？

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

基于采样的热点探测（Sample Based Hot Spot Detection）：采用这种方式的虚拟机会周期性地检查各个线程的栈顶，如果发现某个（或某些）方法经常出现在栈顶，那这个方法就是“热点方法”，基于采样的热点探测的好处是实现简单，高效，还可以很容易地获取方法调用关系（将调用堆栈展开即可），缺点是很难精确的确认一个方法的热度，容易因为受到线程阻塞或别的外界因素的影响而扰乱热点探测。

基于计数器的热点探测（Counter Based Hot Spot Detection）：采用这种方式的虚拟机会为每个方法（甚至是代码块）建立计数器，统计方法的执行次数，如果执行次数超过一定的阈值就认为它是“热点方法”。这种统计方法实现起来麻烦一些，需要为每个方法建立并维护计数器，而且不能直接获取到方法的调用关系，但是它的统计结果相对来说更加精确和严谨。

    在Hot Spot虚拟机中使用的是第二种——基于计算器的热点探测方法，因此它为每个方法准备了两类计算器：方法调用计数器（Invocation Counter）和回边计数器（Back Edge Counter）。这两个计数器虚拟机参数，有一个确定的阈值，当计数器超过阈值溢出了，就会触发JIT编译。

    首先来看方法调用计数器，这个计数器就用于统计方法被调用的次数，它的默认阈值在Client模式下是1500次，在Server模式下是10000次，这个阈值可以通过虚拟机参数-XX:COmpileThreshold来人为设定。当一个方法被调用时，会先检查该方法是否存在被JIT编译过的版本，如果存在，则优先使用编译后的本地代码来执行。如果不存在已被编译过的版本，则将此方法的调用计数器值加1，然后判断方法调用计数器与回边计数器值之和是否超过方法调用计数器的阈值。如果已超过阈值，那么会向即时编译器提交一个该方法的代码编译请求。

    如果不做任何设置，执行引擎并不会同步等到编译请求完成，而是继续进入解释器按照解释方式执行字节码，直到提交的请求被编译器编译器完成。当编译工作完成之后，这个方法的调用入口地址就会被系统自动改写成新的，下一次调用该方法时就会使用以编译的版本。整个JIT编译的交互过程如下图所示：

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

    现在看看另一个计数器——回边计数器，它的作用是统计一个方法中循环体代码执行的次数，在字节码中遇到控制流向后跳转的指令称为“回边”（Back Edge）。显然，建立回边计数器统计的目的就是为了触发OSR编译。

    关于回边计数器的阈值，虽然HotSpot虚拟机也提供了一个类似于方法调用计数器阈值-XX：CompileThreshold的参数-XX：BackEdgeThreshold供用户设置，但是当前的虚拟机实际上并未使用此参数，因为我们需要设置另外一个参数-XX：OnStackReplacePercentage来间接调整回边计数器的阈值，其计算公式如下：

    虚拟机运行在Client模式下，回边计数器阈值计算公式为：

    方法统计计数器阈值（CompileThreshold）XOSR比率（OnStackReplacePercentage）/100

    其中OnStackReplacePercentage默认值为933，如果都取默认值，那Client模式虚拟机 的回边计数器的阈值为13995。

    虚拟机运行在Server模式下，回边计数器阈值的计算公式为：

    方法调用计数器阈值(CompileThreshold)X(OSR比率（OnStackReplacePercentage）——解释器监控比率（InterpreterProfilePercentage）/100

    其中OnStackReplacePercentage默认值为140，InterpreterProfilePercentage默认值为33，如果都取默认值，那Server模式虚拟机回边计数器的阈值为10700。

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

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

    上面两张图都是描述了Client VM的即时编译方式，对于Server VM来说，执行情况会比上面的描述更复杂一些。

编译过程

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

    Server Compiler和Client Compiler两个编译器的编译过程是不一样的。对于Client Compiler来说，它 是一个简单快速的三段式编译器，主要的关注点在于局部性的优化，而放弃了许多耗时较长的全局优化手段。

    在第一个阶段，一个平台独立的前端将字节码构造成一种高级中间代码表示（High-Level Intermediate Representaion，HIR）。HIR使用静态单分配（Static Signle Assignment，SSA）的形式来表示代码值，这可以使得一些在HIR的构造过程之中和之后进行的优化动作更容易实现。在此之前编译器会在字节码上完成一部分基础优化，如方法内敛、常量传播等优化将会在字节码被构成HIR之前完成。

    在第二个阶段，一个平台相关的后端使用线性扫描算法（Linear Scan Register Allocation）在LIR上分配寄存器，并在LIR上做窥孔（Peephole）优化，然后产生机器代码。Client Compiler的大致过程如下所示：

   而Server Compiler则是专门面向服务端的典型应用并未服务端的性能配置特别调整过的编译器，也是一个充分优化过的高级编译器，几乎能达到GUN C++编译器使用-02c参数时的优化强度。

    以即时编译的标准来看，Server Compile无疑是比较缓慢的，但它的编译速度依然远远超过传统的静态优化编译器，而且它相对于Client Compiler编译输出的代码质量有所提高，可以减少本地代码的执行时间，从而抵消了额外的编译时间开销，所有也有很多非服务端的应用选择使用Server模式的虚拟机运行。