晚期（运行期）优化

目录

1、概述

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

1、解释器与编译器

2、编译对象和触发条件

方法调用计数器

回边计数器

3、编译过程

Client Compiler

Server Complier

3、编译优化技术

公共表达式消除

数组边界检查消除

方法内联

逃逸分析

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

1、概述

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

即时编译器并不是虚拟机必需的部分。但是，即时编译器编译性能的好坏、代码优化程度的高低却是衡量一款商用虚拟机优秀与否的最关键的指标之一，它也是虚拟机中最核心且最能体现虚拟机技术水平的部分。

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

1、解释器与编译器

• 解释器：当程序需要迅速启动和执行的时候，解释器可以首先发挥作用，省去编译的时间，立即执行。节省内存。可作为编译器激进优化的一个逃生门，称为逆优化。
• 编译器：把越来越多的代码编译成本地代码之后，可以获取更高的执行效率。提高效率。

HotSpot虚拟机中内置了两个即时编译器，分别称为Client Compiler和Server Compiler，或者简称为C1编译器和C2编译器（也叫Opto编译器）。

程序使用哪个编译器，取决于虚拟机运行时的模式。

解释器和编译器搭配使用被称为混合模式（mixed mode），也可以强制虚拟机运行于编译模式（compiled mode）或者 解释模式（interpreted mode）。

为了在程序启动响应速度与运行效率之间达到最佳平衡，HotSpot虚拟机会逐渐启用分层编译（Tiered Compilation）的策略。

分层编译根据编译器编译、优化的规模与耗时，划分出不同的编译层次，其中包括：

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

实施分层编译后，Client Compiler和Server Compiler将会同时工作，许多代码都可能会被多次编译，用Client Compiler获取更高的编译速度，用Server Compiler来获取更好的编译质量，在解释执行的时候也无须再承担收集性能监控信息的任务。

2、编译对象和触发条件

热点代码：被多次调用的方法、被多次执行的循环体

两者都以整个方法体作为编译对象进行编译，这种编译方式因为编译发生在方法执行过程中，因此形象地称之为栈上替换（OSR编译），即方法栈帧还在栈上，方法就被替换了。

判断一段代码是不是热点代码，是不是需要触发即时编译，这种行为称为热点探测。

• 基于采样的热点探测：虚拟机会周期性地检查各个线程的栈顶，如果发现某个方法检经常出现在栈顶，那这个方法就是"热点方法"。基于采样的热点探测的好处是:简单，高效，还可以很容易地获取调用关系，但很难精确地确认一个方法的热度，容易因为受到线程阻塞或别的外界因素影响而扰乱热点探测。
• 基于计数器的热点探测:采用这种方法的虚拟机会为每个方法建立计数器，统计方法的执行次数，若执行次数超过一定程度则说明该方法是热点方法。好处是统计结果紧确，坏处是要维护一个计数器。

HotSpot是使用第二种热点探测方法。因此它为每个方法都准备了两个计数器：方法调用计数器和回边计数器。这两个计数器都有一个确定的阀值，当计数器超过了阀值就会触发JIT编译。

方法调用计数器

这个计数器用于统计方法被调用的次数，阈值可以通过-XX:CompilerThreshold来人为设定。

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

方法调用计数器统计的并不是方法被调用的绝对次数，而是一个相对次数，即一段时间之内方法被调用的次数。

当超过一定的时间限度，如果方法的调用次数仍然不足以让它提交给即时编译器，那这个方法的调用计数器值就会减少一半，这个过程称为方法调用计数器热度的衰减，而这段时间就称为此方法统计的半衰周期。

可以使用虚拟机参数-XX: -UseCounterDecay来关闭衰减，让方法计数器统计方法调用的绝对次数，这样只要系统运行时间足够长，绝大部分方法都会被编译成本地代码。

回边计数器

作用是统计一个方法中循环体代码执行的次数（准确地讲，应该是回边的次数而不是循环次数），在字节码中遇到控制流向后跳转的指令称为"回边"。

1. 当解释器遇到一条回边指令时，会先查找将要执行的代码片段是否有已编译好的版本，如果有将会优先执行已编译的代码。
2. 否则就把回边计数器的值加一，然后判断方法调用计数器与回边计数器值之和是否超过回边计数器的阈值。
3. 当超过阈值的时候会提交一个OSR编译请求，并把回边计数器的值降低一点，以便继续在解释器中执行循环，等待编译器输出编译结果。
4. 回边计数器没有计数衰减的过程，因此这个计数器统计的就是该方法循环执行的绝对次数。
5. 当该计数器溢出时，它还会把方法计数器的值也调整到溢出的状态，这样下次再进入该方法时就会执行标准编译过程。

3、编译过程

默认设置下，无论是方法调用产生的即时编译请求，还是OSR编译请求，虚拟机在代码还未完成之前，都仍然按照解释方式继续执行而编译动作则在后台的编译线程中进行。

用户可以通过参数-XX: -BackgroundCompilation来禁止后台编译，禁止后台编译后，一旦达到JIT的编译条件，执行线程向虚拟机提交编译请求后将会一直等待，直到编译过程完成后再开始执行编译器输出的本地代码。

在后台的编译过程中，C1和C2两个编译器的编译过程是不一样的：

Client Compiler

三段式编译器，主要关注点在局部性的优化，放弃了许多耗时较长的全局优化手段

• 第一个阶段，一个平台独立的前端将字节码构造成一种高级中间代码表示(HIR),一部分基础优化如：方法内联，常量传播等优化将会再字节码被构造成HIR之前完成。
• 第二个阶段，一个平台相关的后端从HIR中产生低级中间代码表示(LIR)，而在此之前会在HIR上完成另一种优化，如空值检查消除，范围检查消除，以便让HIR达到更高效的代码表示形式。
• 最后阶段是在平台相关的后端使用线性扫描算法在LIR上分配寄存器，并在LIR上做窥孔优化，然后产生机器代码。

Server Complier

专门面向服务端，并为服务端的性能配置特别调整过的编译器，也是一个充分优化过的高级编译器，它会执行所有经典的优化动作，如无用代码消除，循环展开，循环表达式外提，消除公共子表达式，常量椽笔，基本块重排序等.

还会实施一些与Java语言特性密切相关的优化技术，如范围检查，空值检查消除等。

还可能根据解释器或Client Compiler提供的性能监控信息，进行一些不稳定的激进优化，如守护内联，分支频率预测等。

3、编译优化技术

• 语言无关的经典优化技术之一：公共子表达式消除
• 语言相关的经典优化技术之一：数组范围检查消除
• 最重要的优化技术之一：方法内联
• 最前沿的优化技术之一：逃逸分析

公共表达式消除

• 如果一个表达式E已经计算过了，并且从先前的计算到现在E中所有变量的值都没有发生变化，那么E的这次出现就成为了公共子表达式。对于这种表达式，直接把前面的计算出的值替换掉它即可。
• 优化仅限于程序的基本块内 – 局部公共子表达式消除（Local Common Subexpression Elimination）;
• 优化的范围涵盖了多个基本块 – 全局公共子表达式消除（Global CommonSubexpression Elimination）

int d = (c * b) * 12 + a + (a + b * c);

b*c被多次计算，且值相等，可以直接把结果替换该式子，减少计算。

int d = E * 12 + a + (a + E);

编译器还可能进一步将其化简为:

int d = E * 13 + a * 2;

数组边界检查消除

Java是一门动态安全的语言，对数组的访问不像C/C++一样，Java在访问数组元素的时候会进行上下界的范围检查，检查是否会越界，如果会则抛出异常，可以抵御大部分的溢出攻击。

在Java语言中访问数组元素foo[i]的时候系统将会自动进行上下界的范围检查，即检查i必须满足i＞=0＆＆i＜foo.length这个条件，否则将抛出一个运行时异常：java.lang.ArrayIndexOutOfBoundsException。 但是对于虚拟机的执行子系统来说，每次数组元素的读写都带有一次隐含的条件判定操作，对于拥有大量数组访问的程序代码　– 性能负担。

如果编译器只要通过数据流分析就可以判定循环变量的取值范围永远在区间[0，foo.length）之内，那在整个循环中就可以把数组的上下界检查消除，这可以节省很多次的条件判断操作。

两种思路：

• 尽可能把 运行期检查 提到 编译期 完成
• 隐式异常处理

if (foo != null) {
     return foo.value;
    } else {
     throw new NullPointerException();
}

// 虚拟机隐式优化
try {
    return foo.value;
} catch (Segment_Fault e) {
    uncommon_trap(e);
}

虚拟机会注册一个Segment Fault信号的异常处理器（伪代码中的uncommon_trap（）），这样当foo不为空的时候，对value的访问是不会额外消耗一次对foo判空的开销的。

代价就是当foo真的为空时，必须转入到异常处理器中恢复并抛出NullPointException异常，这个过程必须从用户态转到内核态中处理，结束后再回到用户态，速度远比一次判空检查慢。

当foo极少为空的时候，隐式异常优化是值得的，但假如foo经常为空的话，这样的优化反而会让程序更慢，HotSpot虚拟机会根据运行期收集到的Profile信息自动选择最优方案。

方法内联

方法内联的主要两个目的：

• 一是去除方法调用的成本（如建立栈帧等）
• 二是为其他优化建立良好的基础，方法内联膨胀之后可以便于在更大范围上采取后续的优化手段，从而获取更好的优化效果。

方法内联的优化行为只是把目标方法的代码“复制”到发起调用的方法之中，避免发生真实的方法调用而已。

但是即时编译器其实还是做了很多工作的，否则无法进行内联 – 因为Java中只有使用invokespecial指令调用的私有方法、实例构造器、父类方法以及使用invokestatic指令进行调用的静态方法才是在编译期进行解析的，除了上述4种方法之外，其他的Java方法调用都需要在运行时进行方法接收者的多态选择，并且都有可能存在多于一个版本的方法接收者（final方法使用invokevirtual指令调用，但也是非虚方法），简而言之，Java语言中默认的实例方法是虚方法。

对于一个虚方法，编译期做内联的时候根本无法确定应该使用哪个方法版本。

为了解决虚方法的内联问题，Java虚拟机引入了”类型继承关系分析”（Class Hierarchy Analysis,CHA）技术，其基于整个应用程序的类型进行分析，用于确定在目前已加载的类中，某个接口是否有多于一种的实现，某个类是否存在子类、子类是否为抽象类等信息。

编译器在进行内联时，如果是非虚方法，那么直接进行内联就可以了，这时候的内联是有稳定前提保障的。如果遇到虚方法，则会向CHA查询此方法在当前程序下是否有多个目标版本可供选择，如果查询结果只有一个版本，那也可以进行内联，不过这种内联就属于激进优化，需要预留一个“逃生门”（Guard条件不成立时的Slow Path），称为守护内联（Guarded Inlining）。

如果程序的后续执行过程中，虚拟机一直没有加载到会令这个方法的接收者的继承关系发生变化的类，那这个内联优化的代码就可以一直使用下去。但如果加载了导致继承关系发生变化的新类，那就需要抛弃已经编译的代码，退回到解释状态执行，或者重新进行编译。

如果向CHA查询出来的结果是有多个版本的目标方法可供选择，则编译器会使用内联缓存（Inline Cache）来完成方法内联，这是建立在目标方法正常入口之前的缓存，它的工作原理大致是：在未发生方法调用之前，内联缓存状态为空，当第一次调用发生后，缓存记录下方法接收者的版本信息，并且每次进行方法调用时都比较接收者版本，如果以后进来的每次调用的方法接收者版本都是一样的，那这个内联还可以一直用下去。

如果方法接收者不一致 – 说明程序真正使用了虚方法的多态特性，这时才会取消内联，查找虚方法表进行方法分派。

所以，在许多情况下，虚拟机进行的内联都是一种激进优化。

逃逸分析

逃逸分析的基本行为就是分析对象动态作用域：当一个对象在方法中被定义后，它可能被外部方法所引用，例如作为调用参数传递到其他方法中，称为方法逃逸。甚至还有可能被外部线程访问到，譬如赋值给类变量或可以在其他线程中访问到的实例变量，成为线程逃逸。

如果能证明一个方法不会逃逸到其他方法或者线程之内，则可以对该方法进行进一步的优化:

• 栈上分配:如果确定一个对象不会逃逸到其他方法上的话，可以将该对象的内存在栈上分配，而不是在堆上分配，减少垃圾回收的压力。
• 同步消除:如果确定一个变量不会逃逸到其他线程的话，可以消除对该变量的同步措施。
• 标量替换:标量指一个数据已经无法在分解成更小的数据来表示。例如Java中的基本类型，都不能被进一步分解，因此它们就是标量，如果一个对象不会逃逸到其他方法中的话，可以不用创建该对象，改为直接创建该对象的若干个成员变量和方法。将这些成员变量和方法创建在栈上。

但是目前还不能保证逃逸分析的性能收益高于它的消耗。

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

1、Java与C/C++的编译器对比代表了最经典的即时编译器与静态编译器的对比。

2、Java虚拟机的即时编译器相较于C/C++静态编译器的性能劣势：

1. 即时编译器运行占用的是用户程序的运行时间
2. Java语言是动态的类型安全语言，这就意味着要由虚拟机来确保程序不会违反语言语义或访问非结构化内存
3. Java语言中虽然没有virtual关键字，但是使用虚方法的频率却大于C/C++，这意味运行时对方法接收者进行多态选择的频率要大于C/C++语言，也意味着即时编译器在进行一些优化时的难度要大于C/C++的静态优化编译器
4. Java语言是可以动态扩展的语言，编译器不得不时刻注意并着类型的变化而在运行时撤销或重新进行一些优化
5. Java语言中对象的内存分配都是在堆上进行的，只有方法中的局部变量才能在栈上分配。而C/C++的对象则有多种内存分配方式，既能在堆上分配，又能在栈上分配

3、优势：

1. java开发效率得到提高
2. 在C/C++中别名分析的难度远高于java
3. C/C++编译器所有优化都在编译期完成，以运行期性能监控为基础的优化措施它都无法进行