Java虚拟机晚期(运行期)优化

概述

Java程序最初是通过解释器进行解释执行的，当虚拟机发现某个代码或代码块的运行特别频繁时，就会把这些代码认定为热点代码(Hot Spot Code)，在运行时，虚拟机会把这些代码编译成与本地平台相关的机器码，并进行各种层次的优化，完成这个任务的编译器称为即时编译器(JIT)。

HotSpot虚拟机内的即时编译器

解释器与编译器

解释器与编译器两者各有优势：当程序需要迅速启动和执行的时候，解释器可以首先发挥作用，省去编译的时间。在程序运行后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码之后，可以获得更高的执行效率。当程序运行环境中内存资源限制较大，可以使用解释执行节约内存，反之可以使用编译执行来提升效率。同时，解释器还可以作为编译器激进优化时的一个逃生门，让编译器根据概率选择一些大多数时候都能提升运行速度的优化手段，当激进优化的假设不成立，如加载了新类后类型继承结构出现变化、出现罕见陷阱时可以通过逆优化退回到解释状态继续执行。因此，解释器与编译器经常配合工作，如下图所示：

HotSpot中内置了两个即时编译器，分别是Client Compiler和Server Compiler，简称为C1和C2编译器。虚拟机默认采用解释器与其中一个编译器直接配合的方式工作，程序使用那个编译器，取决于虚拟机运行的模式，HotSpot虚拟机会根据自身版本与宿主机器的硬件性能自动选择运行模式，用户也可以使用-client或-server参数去强制指定虚拟机运行在Client模式或Server模式。无论采用哪种编译器，解释器与编译器搭配使用的方式称为“混合模式”(Mixed Mode)。

由于即时编译器编译代码需要占用程序运行时间，要编译出优化程度更高的代码，所花费的时间可能更长，而且想要编译出优化程度更高的代码，解释器可能还要替编译器收集性能监控信息，这对解释执行的速度也有影响。为了在程序启动响应速度与运行效率之间达到最佳平衡，HotSpot会逐渐启用分层编译(Tiered Compilation)的策略，根据编译器编译、优化的规模与耗时，划分出不同的编译层次，其中包括：

• 第0层，程序解释执行，解释器不开启性能监控功能，可触发第一层编译；
• 第一层，也称为C1编译，将字节码编译为本地代码，进行简单、可靠的优化，如有必要将加入性能监控的逻辑；
• 第2层，也称为C2编译，也是将字节码编译为本地代码，但是会启用一些编译耗时较长的优化，甚至会根据性能监控信息进行一些不可靠的激进优化。

编译对象与触发条件

会被即时编译器编译的热点代码有两类：被多次调用的方法、被多次执行的循环体(栈上替换，On Stack Replacement)。

判断一段代码是不是热点代码，是不是需要触发即时编译，这样的行为称为热点探测(Hot Spot Detection)，主要的热点探测方式有两种：

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

HotSpot使用基于计数器的热点探测方法，他为每个方法准备了两个计数器：方法调用计数器(Invocation Counter)和回边计数器(Back Edge Counter)。这两个计数器都有一个确定的阈值，当计数器超过阈值溢出了，就会触发JIT编译。

方法调用计数器

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

方法调用计数器统计的是方法在一段时间内被调用的次数，当超过一定的时间限度，如果方法的调用次数扔不足以让它提交给即时编译器编译，那这个方法的调用计数器就会被减少一半，这个过程称为方法调用计数器热度的衰减(Counter Decay)，而这段时间就称为此方法统计的半衰周期(Counter Half Life Time)。进行热度衰减的动作是在虚拟机进行垃圾收集时顺便进行的，可以使用虚拟机参数-XX：-UseCounterDecay来关闭热度衰减，让方法计数器统计方法调用的绝对次数，这样，只要系统运行时间足够长，绝对大部分方法都会被编译成本地代码。

回边计数器

在Client模式，回边计数器阈值公式为：方法调用计数器阈值×OSR比率(OnStackReplacePercentage)/100。默认为13995。

在server模式下，回边计数器阈值公式为：方法调用计数器阈值×(OSR比率-解释器监控比率)/100。默认为10700。

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

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

编译过程

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

Client Compiler编译过程：

• 第一个阶段，一个平台独立的前端将字节码构造成一种高级中间代码表示(High-Level Intermediate Representation，HIR)。HIR使用静态单分配(SSA)的形式来代表代码值，这可以使得一些在HIR的构造过程之中和之后进行的优化动作更容易实现。在此之前编译器会在字节码上完成一部分基础优化，如方法内联、常量传播等优化会在字节码构造成HIR之前完成；
• 第二个阶段，一个平台相关的后端从HIR中产生低级中间代码表示(LIR)，而在此之前会在HIR上完成另外一些优化，如空值检查消除、范围检查消除等，以便让HIR达到更高效的代码表示形式；
• 最后阶段是在平台相关的后端使用线性扫描算法(Linear Scan Register Allocation)在LIR上分配寄存器，并在LIR上做窥孔(Peephole)优化，然后产生机器代码。

Server Compiler编译过程：

Server Compiler是专门面向服务端的典型应用并为服务端的性能配置特别调整过的编译器，他会执行所有的经典的优化动作：无用代码消除(Dead Code Elimination)、循环展开(Loop Unrolling)、循环表达式外提(Loop Expression Hoisting)、消除公共子表达式(Common Subexpression Elimination)、常量传播(Constant Propagation)、基本块重排序(Basic Block Recording)等，还会实施一些与Java语言密切相关的优化技术，如范围检查消除(Range Check Elimination)、空值检查消除(Null Check Elimination)等。另外，还可能根据解释器或Client Compiler提供的性能监控信息，进行一些不稳定的激进优化，如守护内联(Guarded Inlinking)、分支频率预测(Branch Frequency Prediction)等。

Server Compiler的寄存器分配器是一个全局图着色分配器，它可以充分利用某些处理器架构上的大寄存器集合。Server Compiler是比较缓慢的，但他的编译速度远超传统的静态优化编译器，而且他相对于Client Compiler编译输出的代码质量有所提高，可以减少本地代码的执行时间，从而抵消了额外的编译时间开销，所以也有很多非服务端应用选择使用Server模式的虚拟机运行。

查看及分析即时编译结果

可以用参数： -XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining在代码运行时查看即时编译和内联信息，如下一段代码：

public class JITTest {
    public static final int NUM = 15000;

    public static int doubleValue(int i){
        for(int j = 0; j < 100000; j++);
        return i*2;
    }

    public static long calcSum(){
        long sum = 0;
        for(int i = 1; i <= 100; i++){
            sum += doubleValue(i);
        }
        return sum;
    }

    public static void main(String[] args) {
        for (int i = 0; i < NUM; i++){
            calcSum();
        }
    }
}

控制台输出信息如下：

    346   40       3       compilerTest.JITTest::calcSum (26 bytes)
                              @ 12   compilerTest.JITTest::doubleValue (18 bytes)   inlining prohibited by policy
    347   41 %     4       compilerTest.JITTest::calcSum @ 4 (26 bytes)
                              @ 12   compilerTest.JITTest::doubleValue (18 bytes)   inline (hot)
    349   42       4       compilerTest.JITTest::calcSum (26 bytes)
                              @ 12   compilerTest.JITTest::doubleValue (18 bytes)   inline (hot)
    351   40       3       compilerTest.JITTest::calcSum (26 bytes)   made not entrant

可以看到，doubleValue方法已经内联到calaSum方法中了。

编译优化技术

虚拟机团队把对代码的优化措施都集中在了即时编译器中。

公共子表达式消除

公共子表达式消除的含义是：如果一个表达式E已经计算过了，并且从先前的计算到现在E中所有变量的值都没有发生变化，那么E的这次出现就成为了公共子表达式。对于这种表达式，没必要再进行计算，用之前的计算结果代替E就好了。

数组边界检查消除

数组边界检查消除是即时编译器中的一项语言相关的经典优化技术。Java在编译期会检查数组下标那么执行时候就没必要判断了。当数组访问发生在循环中，并使用循环变量来访问数组元素，编译期只要通过数据流分析就可以判定循环变量的取值范围没有越界，那么在循环中就可以把数组的上下界检查消除，可以节省很多次的条件判断操作。虽然Java提供了安全检查，省去了许多麻烦，但也导致运行速度比C++慢。要消除这些隐式开销，除了数组检查这种把运行期检查提到编译期完成的思路外，还有另外一种思路——隐式异常处理，Java中空指针检查和算术运算中除数为零的检查都采用了这种思路。例如虚拟机在隐式异常优化一个NullPointException后，会注册一个Segment Fault信号的异常处理器，这样try中不出现异常就不会额外判断一次try语句中的内容是否空指针异常，代价就是若真的出现异常，必须转入异常处理器并抛出NullPointException异常，这个过程必须从用户态转到内核态处理，结束后再返回到用户态，速度远比一次判空慢。HotSpot会根据运行期收集到的Profile信息自动选择最优方案。

方法内联

方法内联是编译器最重要的优化手段之一，除了消除方法调用的成本外，它更重要的意义是为其他优化手段建立良好的基础。Java中的方法默认为虚方法，在编译期无法确定方法版本，就无法内联。

为了解决虚方法的内联问题，Java虚拟机团队先是引入了类型继承关系分析(CHA)的技术，他用于确定在目前已加载的类中，某个接口是否有多于一种的实现，某个类是否存在子类、子类是否为抽象类等信息。编译器在进行内联时，如果是非虚方法，那么直接进行内联就可以了。如果是虚方法，会向CHA查询此方法在当前程序下是否有多个目标版本可供选择，如果查询结果只有一个版本，那也可以进行内联，不过这种内联属于激进优化，需要预留一个逃生门，称为守护内联。在后续过程中，如果加载了导致继承关系变化的新类，就需要抛弃已经编译的代码，退回到解释状态执行，或重新编译。如果查询结果是有多个版本的目标方法进行选择，编译器会使用内联缓存来完成方法内联，则是建立在目标方法正常入口之前的缓存，它的工作原理大致是：在未发生方法调用之前，内联缓存状态为空，当第一次调用发生后，缓存记录下方法接受者的版本信息，并且每次发生方法调用时都比较接收者版本，如果以后的版本都是一样的，内联就可以一直用下去，如果不一致，就取消内联，查找虚方法表进行方法分派。

逃逸分析(Escape Analysis)

逃逸分析与类型继承关系分析一样，并不是直接优化代码的手段，而是为其他优化手段提供依据的分析技术。逃逸分析的基本行为就是分析对象动态作用域：当一个对象在方法中被定义后，他可能被外部方法所引用，例如作为调用参数传递到其他方法中，称为方法逃逸。甚至还可能被外部线程访问，称为线程逃逸。如果证明对象不会逃逸，就可以为这个变量做一些高效的优化，例如：

• 栈上分配：如果证明一个对象不会逃逸到方法外面，可以让这个对象在栈上分配内存，对象所占用的内存空间就会随栈帧出栈而销毁，减少gc压力；
• 同步消除：线程同步本身是一个相对耗时的过程，如果逃逸分析能够确定一个变量不会逃逸出线程，可以对这个变量实施同步消除；
• 标量替换：标量(Scalar)是指一个数据已经无法再分解成更小的数据来表示了，Java虚拟机中的原始数据类型都无法分解，它们可以成为标量。相对的，如果一个数据可以继续分解，他就称作聚合量(Aggregate)，对象就是典型的聚合量。如果把一个对象拆散，根据程序访问的情况，将其使用到的成员变量恢复原始类型来访问就叫做标量替换。如果逃逸分析证明一个对象不会被外部访问，并且这个对象可以被拆散的话，那程序执行时就可能不创建这个对象，直接创建若干成员变量来代替。将对象拆分后，除了可以让对象的成员变量在栈上分配和读写之外，还可以为后续进一步优化手段创造条件。