深入理解Java虚拟机—后端编译与优化

上一篇：深入理解Java虚拟机—前端编译与优化

下一篇：深入理解Java虚拟机—Java内存模型与线程

后端编译与优化

如果我们把字节码看作是程序语言的一种中间表示形式的话，那编译器无论在何时、何种状态下把Class文件转换成与本地基础设施相关的二进制机器码，都可以视为整个编译过程的后端

一. 即时编译器

Java程序最初都是通过解释器执行的，当虚拟机发现某个方法执行得特别频繁时，就认定它们为热点代码，为了提高热点代码的执行速度，就会把他们编译为本地机器码，执行这些操作的就是即时编译器

1. 解释器与编译器

• 解释器与编译器配合使用的方式在虚拟机中被称为“混合模式（Mixed Mode），为默认模式
• 可以使用参数 -Xint 强制虚拟机运行于“解释模式（Interpreter Mode）”
• 可以使用参数 -Xcomp 强制虚拟机运行于“编译模式（Compiled Mode）”

解释器与编译器:

• 目前主流的java虚拟机内部都同时包含解释器与编译器。当程序需要迅速启动和执行的时候，解释器可以首先发挥作用，省去编译的时间，立即运行。当程序启动后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码，这样可以减少解释器的中间损耗，获得更高的执行效率。
• 解释器与编译器经常是相辅相成地配合工作。解释器还可以作为编译器激进优化时后备的“逃生门”，如加载了新类以后，类型继承结构出现变化、出现“罕见陷阱时”可以通过逆优化退回到解释状态继续执行

在主流JVM中，都是解释器与编译器共存的。
解释器的优势是：不需要额外执行编译过程就可以立即运行。
编译器的作用：它会将一些使用频繁的代码(热点代码),编译为本地字节码，来减少中间消耗，获得较高的执行效率

由于即时编译器编译本地代码本身是需要占用程序运行时间的，而且可能需要解释器替编译器收集性能监控信息，这对解释执行期间也会产生影响。
所以便从直接搭配的工作方式转变为分层编译(JDK6基本实现(需要用-XX:TieredCompilation参数手动开启)，JDK7为服务端模式JVM默认策略)

分层编译根据编译器编译、优化的规模与耗时，划分为不同的编译层次。

0：程序纯解释，解释器不开启性能监控功能
1：使用客户端编译器将字节码编译为本地代码来运行，进行简单可靠的优化，不开启性能监控功能。
2：使用客户端编译器，仅开启方法及回边(从循环边界往回跳转)次数统计等有限的性能监控。
3：客户端编译器，全面开启性能监控，还会收集分支跳转，虚方法调用版本等全部统计信息。
4：使用服务器编译器，会根据监控信息进行一些不可靠的激进优化。

层次转换图如下所示：

2. 编译对象与触发条件

主要分为两部分：

• 被多次调用的方法
• 被多次执行的循环体(编译的仍是循环体所属方法，不过不过会传入执行入口点紫萼解码序号(CBI),这种在方法栈帧仍在栈上,方法就被替换，形象的被称为栈上替换)

那么多次如何定义？

要知道某段代码是不是热点代码，是不是需要触发即时编译，这个行为被称为“热点探测”（Hot Spot Code Detection），目前主流的有两种方式：

• 基于采样的热点探测:周期性检查栈顶，如果发现某些方法经常出现在栈顶便是热点方法。(简单高效可获得调用关系,但很难精确的确认一个方法的热度，易受线程阻塞等因素的影响)
• 基于计数器的热点探测 (HotSpot采用的方式)，为每个方法体/代码块 创建计数器，统计计数器次数，如果执行次数超过预定的阈值则认为为热点(稍微复杂，不能直接获取调用关系,每个方法都需要维护一个计数器，但是精确)

J9编译器采用过第一种采样热点探测，而HotSpot采用的是第二种基于计数器的方法，HotSpot为每个方法准备了两类计数器：方法调用计数器（Invocation Counter）和回边计数器（Back Edge Counter），回边计数器的作用是统计一个方法中循环体代码执行的次数，在字节码中遇到控制流向后跳转的指令就称为回边（Back Edge）

当发生JIT时，执行引擎是不会同步等待的，而是继续按照解释器执行字节码，不过当编译完成后，该方法的调用入口便会被系统自动替换为新值。

客户端方法调用计数器判定流程:
当一个方法被调用时，虚拟机会先检查该方法是否存在被即时编译过的版本，如果存在，则优先使用编译后的本地代码执行。如果不存在已被编译过版本，则将该方法的调用计数器值加一，然后判断方法调用计数器与回边计数器值之和是否超过方法调用计数器的阙值。一旦超过阙值，将会向即时编译器提出一个该方法的代码编译请求。流程如下图所示：

方法计数器：客户端默认1500，服务器默认10000，可用-XX:CompileThreshold设定,不过不是绝对的，有个热度衰减的概念，如果超过一定的时间限度，如果方法的调用次数仍然不足以让它提交给即时编译器，那该方法的调用计数器就会被减半，这个过程被称为方法调用计数器的衰减（Counter Decay），而这段时间就称为该方法统计的半衰周期（Counter Half Life Time）。可以使用虚拟机参数-XX:-UseCounterDecay来关闭热度衰减。另外还可以使用-XX:CounterHalfLifeTime参数设置半衰周期的时间，单位是秒
HotSpot使用另外一个参数-XX:OnStackReplacePercentage来间接调整回边计数器的阙值

客户端回边计数器判定流程:

当一个解释器遇到一条回边指令时，会先检查该执行代码片段是否存在被即时编译过的版本，如果存在，则优先使用编译后的本地代码执行。如果不存在已被编译过版本，则将回边计数器值加一，然后判断方法调用计数器与回边计数器值之和是否超过方法调用计数器的阙值。如果超过阙值，将会提交一个栈上替换编译请求，并且把回边计数器的值稍微降低一些，以便继续在解释器中执行循环，等待编译器输出编译结果。流程如下图所示

客户端回边次数的计算方式： 以方法调用计数器阈值(-XX:CompileThreshold)乘以OSR比率(-XX：OnStackReplacePercentage(默认值为933))除以100.如果都取默认值，则为13995.
服务器回边次数的计算方式: 法调用计数器阈值(-XX:CompileThreshold)乘以OSR比率(-XX：OnStackReplacePercentage(默认值为933))减去解释器监控比率(-XX:InterpreterProfilePercentage 默认为33)除以100.如果均为默认值，则为10700.
当回边计数器溢出时，也会把方法计数器调整到溢出状态。

注意回边计数器没有热度衰减的过程

3. 编译过程

在默认条件下，无论是方法调用产生的标准编译请求，还是栈上调换编译请求虚拟机在编译器还未完成编译之前，都仍然将按照解释方式继续执行代码，而编译动作则在后台的编译线程中进行。可以使用参数-XX:-BackgroundCompilation来禁止后台编译，这样执行线程会在编译完成之前一直阻塞等待
在允许后台编译的场景下，在编译完全前，JVM仍会按照解释的方式执行。可是如果关闭(-XX:-BackgroundCompilation),则会被阻塞等待编译完成，再运行，并执行编译器输出的本地代码。

客户端：
它是个简单快速的三段式编译器，它放弃了许多耗时较长的全局优化，关注局部优化 :

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

调整过的编译器，也是一个能容忍很高优化复杂度的高级编译器，它会执行大部分经典的优化动作，如:无用代码消除( Dead Code Elimination)、循环展开( Loop Unrolling).、循环表达式外提( Loop Expression Hoisting)、消除公共子表达式 ( Common Subexpression Elimination)、常量传播 (Constant Propagation)、基本快重排序( Basic Block Reordering) , 还会实施一些与Java语言密切相关的优化技术，如范围检查消除( Range Check Elimination)、 空值检查消除(Null Check Elimination,不过并非所有的空值检查消除都是依赖编译器优化的，有一些是代的运行过程中自动优化了)等。另外，还可能根据解释器或客户端编译器提供的性能监控信息，进行一些不稳定的预测性激进优化，如守护内联( Guarded Inlining)、 分支频率预测( Branch Frequency Prediction)等。

服务器端编译与客户端编译相比，无疑是比较缓慢的。但是它输出的代码质量更高，可以大幅减少本地代码的执行实现

4. HotSpot VM 内置的三个即时编译器

• 客户端编译器（Client Compiler），简称 C1 编译器。
• 服务端编译器（Server Compiler），简称 C2 编译器，或 Opto 编译器。
• Graal 编译器（JDK 10 出现，长期目标是替代 C2 编译器）

对比分析

• 程序需要迅速启动和执行时，解释器可以省去编译时间，立即执行。
• 程序启动后，编译器逐渐发挥作用，把越来越多的代码编译成本地代码，可以减少解释器的中间消耗，提高执行效率。
• 若运行环境的内存资源限制较大，可使用解释器执行节约内存；反之可使用编译执行来提升效率。

总结

• 解释器启动较快，占用内存较小，但是执行效率稍低。
• 编译器启动较慢，占用内存较大，但执行效率较高

二. 提前编译器

1. 提前编译器优劣

提前编译器（Ahead Of Time Compiler，AOT编译器）：直接把程序编译成与目标机器指令集相关的二进制代码的过程。目前有两种主要的实现方式：

• 与传统C、C++编译器类似，在程序运行之前把程序代码编译成机器码的静态翻译工作
• 把原本即时编译器在运行时要做的编译工作提前做好并保存下来，下次运行到这些代码（譬如公共库代码在被同一台机器其他Java进程使用）时直接把它加载进来使用

第一种实现方式在Java中的存在价值直指即时编译的最大弱点：即时编译要占用程序运行时间和运算资源。例如最耗时的优化措施之一：过程见分析，必须在全程序范围内做大量耗时的计算工作，如果是在程序运行之前进行的静态编译，这些耗时操作就可以大胆的进行。

对于第二种方式，本质上是给即时编译器做缓存加速，去改善Java程序的启动时间，以及需要一段时间预热之后才能达到最高性能的问题。这种提前编译被称为动态提前编译或者直接叫即时编译缓存。HotSpot运行时可以直接加载这些编译结果，实现快速程序启动速度，减少程序达到全速运行状态所需要的时间。

但是即时编译相比于提前编译也有很多优点：

• 性能分析制导优化。解释器和客户端编译器在运行期间会不断收集性能监控信息，这些信息一般无法在静态分析是获得，或者不一定存在唯一的解，但在动态运行时很容易得到
• 基金预测性优化。静态优化无论何时都必须保证优化后的所有程序外部可见影响（不仅仅是执行结果）与优化前必须是一致的。即时编译的策略就可以不必那么保守，如果性能监控信息能够支持它做出一些正确的可能很大但是无法保证绝对正确的预测判断，就可以进行大胆的优化，大不了退回到低级i按一起甚至解释器上运行。而这样的优化往往能够大幅度降低目标程序的复杂度，输出运行速度非常高的代码
• 链接时优化。由于Java天生是动态连接的，所以提前编译无法做到链接后的优化。

2. 编译器优化技术

编译器的目标虽然是做有程序代码翻译为本地代码的工作，但其实难点并不在于能不能成功翻译出机器码，输出代码优化质量的高低才是决定编译器优秀与否的关建。

HotSpot采用了不少优化手段，其中有不少是经典编译器的优化手段，也有许多针对Java语言，或者说针对运行在Java虚拟机上所有语言进行的优化。

需要明确的一点是，即时编译器对这些代码优化变化交换是建立在代码的中间表示或者机器码之上，绝对不是直接在Java源码上去做的。下面介绍四项有代表性的优化技术

a. 方法内联

方法内联的就是把目标方法的代码原封不动的“复制”到发起调用的方法中，避免发生真实的方法调用。它的主要目的有两个：

• 去除方法调用的成本（如查找方法版本，建立栈桢等）
• 为其他优化建立良好的基础，便于在更大范围上进行后续优化手段，可以获得更好的优化效果。

对于一个虚方法，编译器静态的去做内联的时候很难确定应该使用哪个方法版本。而在Java中，只有使用invokespecial指令调用的私有方法、实力构造器、父类方法和使用invokestatic指令调用的静态方法才会在编译器进行解析，最多再算上被final修饰的方法（虽然他是使用invokevirtual指令调用的）。其他的Java方法调用都必须运行时进行方法接收者的多态选择，它们都可能存在多于一个版本的方法接收者，简而言之，Java语言中默认的实例方法是虚方法。

为了解决虚方法的内敛问题，Java虚拟机引入了**类型继承关系分析（Class Hierarchy Analysis，CHA）**技术。主要用于确定整个应用程序范围内，目前已加载的类中，某个接口是否有多余一种实现、某个类是否存在子类、某个子类是否覆盖了父亲的某个虚方法等信息。

如果是虚方法，那么只进行内联，这种内联是百分之百安全的；如果是虚方法，则会向CHA查询此方法在当前程序状态下是否真的有多个目标版本，如果查询只有一个版本，那么就可以假设“应用程序的全貌就是现在运行的这个样子”来进行内联，这种内联被称为守护内联（Guarded Inlining）。

如果是多个版本的，编译器会使用内联缓存（Inline Cache）的方式来缩减方法调用的开销。内联缓存是一个建立在目标方法正常人口之前的缓存，它的工作原理大致为:在未发生方法调用之前，内联缓存状态为空，当第一次调用发生后，缓存记录下方法接收者的版本信息，并且每次进行方法调用时都比较接收者的版本。如果以后进来的每次调用的方法接收者版本都是一样的，那么这时它就是种单态内联缓存(Monomorphic Inline Cache)。 通过该缓存来调用，比用不内联的非虚方法调用，仅多了一次类型判断的开销而已。但如果真的出现方法接收者不致的情况， 就说明程序用到了 虚方法的多态特性， 这时候会退化成超多态内联缓存(Megamorphic Inline Cache),其开销相当于真正查找虚方法表来进行

在Java虚拟机中运行方法内敛多数情况下是一种激进优化

b. 逃逸分析

逃逸分析的基本原理是：分析对象动态作用域，当一个对象在方法里面被定义之后，它可能被外部方法所引用，例如作为调用参数传入到其他方法中，这种称为方法逃逸；甚至还有可能被外部线程访问到，譬如赋值给可以在其他线程中访问的实例变量，这种称为线程逃逸；从不逃逸、方法逃逸到线程逃逸，称为对象由低到高的不同逃逸程度。

根据逃逸程度可以进行不同程度的优化：

• 栈上分配（Stack Allocation）：在Java虚拟机中，一般是在Java堆上分配创建内存的空间，Java堆中的对象对于各个线程都是共享和可见的，但回收和整理堆内存，都需要消耗大量资源。所以对一个不会逃逸出线程的对象在栈上分配就是一个不错的主意，对象所占用的内存会随着栈桢的出栈而销毁，大量对象会随着方法的结束而自动销毁，垃圾收集子系统的压力会下降不少。栈上分配支持方法逃逸，不支持线程逃逸
• 标量替换（Scalar Replacement）：把Java对象拆散，根据程序访问的情况，将其用到的成员变量恢复为原始类型来访问，这个过程就称为标量替换。假如逃逸分析证明一个对象不会被方法外部访问，并且可以将这个对象拆散，那么程序真正执行的时候就不会去创建该对象，而改为直接创建它的若干个被这个方法使用的成员变量来代替，而且这些成员变量还可以分配在栈上。不过他不允许对象逃逸出方法范围
• 同步消除（Synchronization Elimination）：线程同步本身是一个相当耗时的过程，如果逃逸分析·能够确定一个变量不会逃逸出线程，无法被其他线程访问，那么这个变量的读写肯定就不会有竞争，对这个变量实施的同步措施就可以安全的消除掉。

不过现在逃逸分析仍然不成熟，原因是逃逸分析的计算成本非常高，甚至不能保证逃逸分析带来的性能收益会高于它的消耗。

可以使用参数-XX:+DoEscapeAnalysis来手动开启逃逸分析，使用参数-XX:+PrintEscapeAnalysis来查看分析结果，使用参数-XX:+EliminateAloocations来开启标量替换，使用参数-XX:+EliminateLocks来开启同步消除，使用参数-XX:+PrintEliminateLocks来查看同步消除情况。

下面使用Java伪代码用一个例子展示逃逸分析能够实现的效果：

public int test(int x){
	int xx = x + 2;
    Point p = new (xx, 42);
    return p.getX();
}

第一步，将Point的构造函数和getX方法进行内联优化：

public int test(int x){
	int xx = x + 2;
    Point p = point_memory_alloc(); //在堆内存中分配p对象的示意方法
    p.x = xx;	//Point构造函数被内联后的样子
    p.y = 42;
    return p.x;	//Point::getX()方法被内联后的样子
}

第二步，经过逃逸分析发现Point对象不会发生任何程度的逃逸，所以可以对其进行标量替换

public int test(int x){
	int xx = x + 2;
    int px = xx;	
    int py = 42;
    return px;
}

第三步，无用代码消除

public int test(int x){
	return x + 2;
}

这样就完成了test函数的优化，最后只剩下了一条语句。

3. 公共子表达式消除

公共子表达式消除是一项非常经典、应用普遍的编译器优化技术。其含义为：如果一个表达式E之前就被计算过了，并且先前的计算到现在E中所有变量的值都没有改变过，那么E的这次出现就称为公共子表达式。对于这种表达式，没有必要花时间在对它重新进行计算，只需要直接用前面计算过的表达式结果替代E。

下面举一个简单的例子说明他的优化过程：

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

当这段代码进入编译器后，它将进行如下优化，编译器检测到c * b和b * c是一样的表达式，而且计算期间b与c的值是不变的，则这个表达式可以被视为：

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

这个时候，编译器还可能进行另一种优化：代数简化（Algebraic Simplication），在E本来就有乘法运算的前提下，把表达式变为：

int d = E * 13 + a + a;

表达式转换之后，计算就可以节省一些时间

4. 数组边界检查消除

由于Java语言是一门动态安全检查的语言，对于数组foo[]，访问数组元素foo[i]的时候系统会自动进行上下界范围检查，即i必须满足i>=0 && i<foo.length的访问条件，否则将抛出运行时异常。这样每一次读写都要进行一次检查无疑是一种负担。

有时数组边界检查不是必须继续进行的，此时就可以省略。例如数组下标是一个常量，如foo[3]，只要在编译期根据数据流分析来确定foo.length的值，并判断下表“3”没有越界，执行时的时候就无需判断了。更加典型情况是，对于数组访问发生在循环中，并且使用循环变量对数组进行访问。如果编译器只要通过数据流分析就可以判定循环遍历取值范围永远在[0, foo.length)之内，那就可以把数组边界检查消除。

行一次检查无疑是一种负担。

有时数组边界检查不是必须继续进行的，此时就可以省略。例如数组下标是一个常量，如foo[3]，只要在编译期根据数据流分析来确定foo.length的值，并判断下表“3”没有越界，执行时的时候就无需判断了。更加典型情况是，对于数组访问发生在循环中，并且使用循环变量对数组进行访问。如果编译器只要通过数据流分析就可以判定循环遍历取值范围永远在[0, foo.length)之内，那就可以把数组边界检查消除。