晚期（运行期）优化

1、概述

java程序最初是通过解释器进行解释执行的，当虚拟机发现某个方法或代码块的运行特别频繁，就会把这些代码认定为“热点代码”，为了提高热点代码的执行效率，在运行时，虚拟机会把这些代码编译成与本地平台相关的机器码，并进行各种层次的优化，完成这个任务的编译器称为即时编译器（Just in Time Compiler JIT）.

即时编译器并不是虚拟机必需的部分，java虚拟机规范中并没有规定java虚拟机内必须要有即时编译器，更没有限定或指导即时编译器应该如何去实现。但是即时即时编译器是虚拟机中最能体现技术水平的部分。

2、HotSpot虚拟机内的即时编译器

为何HotSpot虚拟机要使用解释器与编译器并存的架构呢？

为何HotSpot虚拟机要实现两个不同的即时编译器？

程序何时使用解释器执行？何时使用编译器执行？

哪些程序代码会被编译为本地代码？如何编译本地代码？

如何从外部观察即时编译器的编译过程和编译结果？

（1）解释器与编译器

尽管不是所有java虚拟机都采用解释器与编译器并存的架构，但许多主流的虚拟机如HotSpot，J9，都同时包含解释器与编译器，解释器与编译器两者各有优势：当程序需要迅速启动和执行的时候，解释器可以首先发挥作用，省去编译的时间，立即执行。当程序运行后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码后，可以获取更高的执行效率。

（2）编译对象与触发条件

在前面说到运行过程中会被即时编译器编译的“热点代码”有两类:

被多次调用的方法。

被多次执行的循环体。为了解决当一个方法只被调用过一次或几次，但是方法体内部存在循环次数较多的循环体，这样的循环体的代码也会被重复执行多次。

对于第一种情况，由于是由方法调用触发的编译，那编译器会以整个方法作为编译对象，这种编译也是虚拟机中标准的编译方式，而对于后一种情况，尽管编译动作是由循环体所触发的，但是编译器仍然会以整个方法（而不是单独的循环体）作为编译对象，这种编译方式因为编译发生在方法执行过程之中，因此被形象称为栈上替换。

那么“多次执行的方法”，多少次算是“多次呢”？虚拟机如何统计一个方法或一段代码被执行过多少次呢？解决了这两个问题，也就回答了即时编译被触发的条件。

要知道一段代码是不是热点代码，是不是需要触发即时编译，这个行为称为热点探测。热点探测不一定要知道方法具体被调用了多少次，目前主要热点探测判定方式有两种：

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

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

HotSpot虚拟机中使用的是第二种---基于计数器的热点探测方法，因此它为每个方法准备了两个计数器：方法调用技术器（Invocation Counter）和回边计数器（Back Edge Counter）。、

在确定虚拟机运行参数前提下，这两个计数器都有一个确定的阈值，当计数器超过阈值溢出了，就会触发JIT编译、

方法调用计数器，这个计数器是用于统计方法被调用的次数，它默认阈值在client是1500次，在server模式下是10000次，当一个方法被调用时，会先检查该方法是否存在被JIT编译过的版本，如果存在，则优先使用编译后的本地代码来执行，如果不存在已被编译过的版本，则将此方法的调用计数器值加1，然后判断方法调用计数器与回边计数器值之和是否超过方法调用计数器的阈值，如果已超过阈值的话，将会向即时编译器提交一个该方法额的代码编译请求。

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

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

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

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

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

上图都是Client VM的即时编译方式，对于Server VM来说，执行情况会比上面描述的还要复杂。

（3）编译过程

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

那在后台执行编译的过程中，编译器做了什么呢？Server Compiler和Client Compiler两个编译器的编译过程是不一样的，对于Client Compiler，它是一个简单的快速的三段式编译器，主要的关注点在于局部性的优化，而放弃了许多耗时较长的全局优化手段。

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

在第二个阶段，一个平台相关的后端从HIR中产生低级中间代码表示（Low-Level Intermediate Representation,LIR），而在此之前会在HIR上完成另外一些优化，如空值检查消除、范围检查消除等，以便让HIR达到更高效的代码表示形式。

最后阶段是在平台相关的后端使用线性扫描算法（Linear ScanRegister Allocation）在LIR上分配寄存器，并在LIR上做窥孔优化，然后产生机器代码。Clinet Compiler大致过程如图：