第11章 后端编译与优化
概述
如果把字节码看作是程序语言的一种中间表示形式(Intermediate Representation，IR)的话， 那编译器无论在何时、在何种状态下把Class文件转换成与本地基础设施(硬件指令集、操作系统)相关的二进制机器码，它都可以视为整个编译过程的后端。
即时编译器
Java程序最初都是通过解释器(Interpreter)进行解释执行的，当虚拟机发现某个方法或代码块的运行特别频繁，就会把这些代码认定为“热点代码”(HotSpot Code)，为了提高热点代码的执行效率，在运行时，虚拟机将会把这些代码编译成本地机器码，并以各种手段尽可能地进行代码优化，运行时完成这个任务的后端编译器被称为即时编译器。
下面还会解答以下几个问题：
- 为何HotSpot虚拟机要使用解释器与即时编译器并存的架构?
- 为何HotSpot虚拟机要实现两个(或三个)不同的即时编译器?
- 程序何时使用解释器执行?何时使用编译器执行?
- 哪些程序代码会被编译为本地代码?如何编译本地代码?
- 如何从外部观察到即时编译器的编译过程和编译结果?
解释器与编译器
目前主流的商用Java虚拟机，比如HotSpot、OpenJ9等，内部都同时包含解释器与编译器。
解释器与编译器的优势：
- 当程序需要迅速启动和执行的时候，解释器可以首先发挥作用，省去编译的时间，立即运行。
- 当程序启动后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码，这样可以减少解释器的中间损耗，获得更高的执行效率。
- 程序运行环境中内存资源限制较大，可以使用解释执行节约内存，反之可以使用编译执行来提升效率。
-
解释器还可以作为编译器激进优化时后备的“逃生门”，让编译器根据概率选择一些不能保证所有情况都正确，但大多数时候都能提升运行速度的优化手段，当激进优化的假设不成立，如加载了新类以后，类型继承结构出现变化、出现“罕见陷阱”(Uncommon Trap)时可以通过逆优化(Deoptimization)退回到解释状态继续执行
解释器与编译器的交互
HotSpot虚拟机中内置了两个(或三个)即时编译器，其中两个被称为客户端编译器(Client Compiler)和服务端编译器(Server Compiler)，或者简称为C1编译器和 C2编译器，第三个是JDK10才出现的，长期目标是代替C2的Graal编译器。
HotSpot虚拟机会根据自身版本与宿主机器的硬件性能自动选择运行模式，用户也可以使用“-client”或“-server”参数去强制指定虚拟机运行在客户端模式还是服务端模式。
解释器与编译器搭配使用的方式在虚拟机中被称为“混合模式”(Mixed Mode)，可以使用参数“-Xint”强制虚拟机运行于“解释模式”(Interpreted Mode)，可以使用参数“-Xcomp”强制虚拟机运行于“编译模式”(Compiled Mode)，这时候将优先采用编译方式执行程序，但是解释器仍然要在编译无法进行的情况下介入执行过程。
$ java -version
java version "1.8.0_181"
Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)
$ java -Xint -version
java version "1.8.0_181"
Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, interpreted mode)
$ java -Xcomp -version
java version "1.8.0_181"
Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, compiled mode)
由于即时编译器编译本地代码需要占用程序运行时间，通常要编译出优化程度越高的代码，所花时间越长;而且要编译出优化程度更高的代码，解释器可能还要替编译器收集性能监控信息，这对解释执行阶段的速度有所影响。为了在程序启动响应速度与运行效率之间达到最佳平衡，HotSpot虚拟机在编译子系统中加入了分层编译的功能。分层编译根据编译器编译、优化的规模与耗时，划分出不同的编译层次，其中包括:
- 第0层。程序纯解释执行，并且解释器不开启性能监控功能(Profiling)。
- 第1层。使用客户端编译器将字节码编译为本地代码来运行，进行简单可靠的稳定优化，不开启性能监控功能。
- 第2层。仍然使用客户端编译器执行，仅开启方法及回边次数统计等有限的性能监控功能。
- ·第3层。仍然使用客户端编译器执行，开启全部性能监控，除了第2层的统计信息外，还会收集如分支跳转、虚方法调用版本等全部的统计信息。
-
第4层。使用服务端编译器将字节码编译为本地代码，相比起客户端编译器，服务端编译器会启用更多编译耗时更长的优化，还会根据性能监控信息进行一些不可靠的激进优化。
实施分层编译后，解释器、客户端编译器和服务端编译器就会同时工作，热点代码都可能会被多次编译，用客户端编译器获取更高的编译速度，用服务端编译器来获取更好的编译质量，在解释执行的时候也无须额外承担收集性能监控信息的任务，而在服务端编译器采用高复杂度的优化算法时，客户端编译器可先采用简单优化来为它争取更多的编译时间。
分层编译的交互关系
编译对象与触发条件
在运行过程中会被即时编译器编译的目标是“热点代码”，这里所指的热点代码主要有两类，包括:
- 被多次调用的办法：由于是依靠方法调用触发的编译，那编译器理所当然地会以整个方法作为编译对象，这种编译也是虚拟机中标准的即时编译方式。
- 被多次执行的循环体：尽管热点只是方法的一部分，但编译器依然必须以整个方法作为编译对象，只是执行入口(从方法第几条字节码指令开始执行)会稍有不同，编译时会传入执行入口点字节码序号(ByteCodeIndex，BCI)。这种编译方式因为编译发生在方法执行的过程中，因此被很形象地称为“栈上替换”(On Stack Replacement，OSR)，即方法的栈帧还在栈上，方法就被替换了。
要知道某段代码是不是热点代码，是不是需要触发即时编译，这个行为称为“热点探测”(HotSpot Code Detection)，目前主流的热点探测判定方式有两种：
- 基于采样的热点探测(Sample Based Hot Spot Code Detection)。虚拟机会周期检查各线程的调用栈顶，如果某个(或某些)方法经常出现在栈顶，那这个方法就是“热点方法”。优点：实现简单高效，容易获取方法调用关系，缺点是很难精确一个方法的热度，容易受线程阻塞或外界因素影响扰乱热点探测。
- 基于计数器的热点探测(Counter Based Hot Spot Code Detection)。虚拟机会为每个方法(甚至是代码块)建立计数器，统计方法的执行次数，如果执行次数超过一定的阈值就认为是“热点方法”。这种统计方法需要为每个方法建立并维护计数器，而且不能直接获取到方法的调用关系。但统计结果相对精确严谨。
HotSpot虚拟机使用了第二种计数器的热点探测方法： - 方法调用计数器(Invocation Counter)
用于统计方法被调用的次数，默认阈值客户端模式下是1500次，服务端模式下是10000次，阈值通过虚拟机参数-XX:CompileThreshold设定。当一个方法被调用时，虚拟机会先检查该方法是否存在被即时编译过的版本，如果存在，则优先使用编译后的本地代码来执行。如果不存在已被编译过的版本，则将该方法的调用计数器值加一，判断方法调用计数器+回边计数器值之和是>方法调用计数器的阈值。一旦已超过阈值的话，将会向即时编译器提交一个该方法的代码编译请求。
如果没有做过任何设置，执行引擎默认不会同步等待编译请求完成，而是继续进入解释器按照解释方式执行字节码，直到提交的请求被即时编译器编译完成。当编译工作完成后，这个方法的调用入口地址就会被系统自动改写成新值，下一次调用该方法时就会使用已编译的版本了，整个即时编译的交互过程如图11-3所示。
在默认设置下，方法调用计数器统计的并不是方法被调用的绝对次数，而是一段时间之内方法被调用的次数。当超过一定的时间限度，如果方法的调用次数仍然不足以让它提交给即时编译器编译，那该方法的调用计数器就会被减少一半，这个过程被称为方法调用计数器热度的衰减(Counter Decay)，而这段时间就称为此方法统计的半衰周期(Counter Half Life Time)，进行热度衰减的动作是在虚拟机进行垃圾收集时顺便进行的，可以使用虚拟机参数-XX:-UseCounterDecay来关闭热度衰减，让方法计数器统计方法调用的绝对次数，这样只要系统运行时间足够长，程序中绝大部分方法都会被编译成本地代码。另外还可以使用-XX:CounterHalfLifeTime参数设置半衰周期的时间，单位是秒。
回边计数器：作用是统计一个方法中循环体代码执行的次数，在字节码中遇到控制流向后跳转的指令就称为“回边(Back Edge)”，建立回边计数器统计的目的是为了触发栈上的替换编译。设置参数-XX:OnStackReplacePercentage来间接调整回边计数器的阈值，其计算公式有如下两种：
客户端模式下：方法调用计数器阈值(-XX:CompileThreshold)乘以OSR比率(-XX:OnStackReplacePercentage)除以100。其中-XX:OnStackReplacePercentage默认值为933，如果都取默认值，那客户端模式虚拟机的回边计数器的阈值为13995。
-
服务端模式下：方法调用计数器阈值(-XX:CompileThreshold)乘以(OSR比率(-XX:OnStackReplacePercentage)减去解释器监控比率(-XX:InterpreterProfilePercentage)的差值)除以100。其中-XX:OnStackReplacePercentage默认值为140，-XX:InterpreterProfilePercentage默认值为33，如果都取默认值，那服务端模式虚拟机回边计数器的阈值为10700。
与方法计数器不同，回边计数器没有计数热度衰减的过程，因此这个计数器统计的就是该方法循环执行的绝对次数。当计数器溢出的时候，它还会把方法计数器的值也调整到溢出状态，这样下次再进入该方法的时候就会执行标准编译过程。
编译过程
在默认条件下，无论是方法调用产生的标准编译请求，还是栈上替换编译请求，虚拟机在编译器还未完成编译之前，都仍然将按照解释方式继续执行代码，而编译动作则在后台的编译线程中进行。用户可以通过参数-XX:-BackgroundCompilation来禁止后台编译，后台编译被禁止后，当达到触发即时编译的条件时，执行线程向虚拟机提交编译请求以后将会一直阻塞等待，直到编译过程完成再开始执行编译器输出的本地代码。
客户端编译器是一个相对简单快速的三段式编译器，主要的关注点在于局部性的优化：
服务端编译器则是专门面向服务端的典型应用场景，并为服务端的性能配置针对性调整过的编译器，也是一个能容忍很高优化复杂度的高级编译器。会执行大部分经典的优化动作，如:无用代码消除(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)等。
服务端编译采用的寄存器分配器是一个全局图着色分配器。
提前编译器
提前编译的优劣得失
提前编译产品和对其的研究有两条明显的分支，一条分支是做与传统C、C++编译器类似的，在程序运行之前把程序代码编译成机器码的静态翻译工作;另外一条分支是把原本即时编译器在运行时要做的编译工作提前做好并保存下来，下次运行到这些代码(譬如公共库代码在被同一台机器其他Java进程使用)时直接把它加载进来使用。
编译器优化技术
优化技术概览
//优化前的原始代码
static class B {
int value;
final int get() {
return value;
}
}
public void foo() {
y = b.get();
// ...do stuff...
z = b.get();
sum = y + z;
}
- 优化一：方法内联
主要目的：一是去除方法调用的成本(如查找方法版本、建立栈帧等);二是为其他优化建立良好的基础。
//内联后的代码
public void foo() {
y = b.value;
// ...do stuff...
z = b.value;
sum = y + z;
}
- 优化二：冗余访问消除(Redundant Loads Elimination)，假设代码中间注释掉的“...do stuff...”所代表的操作不会改变b.value的值，那么就可以把“z=b.value”替换为“z=y”，因为上一 句“y=b.value”已经保证了变量y与b.value是一致的，这样就可以不再去访问对象b的局部变量了。如果 把b.value看作一个表达式，那么也可以把这项优化看作一种公共子表达式消除(Common Subexpression Elimination)
//冗余存储消除的代码
public void foo() {
y = b.value;
// ...do stuff...
z = y;
sum = y + z;
}
- 优化三：复写传播(Copy Propagation)，因为这段程序的逻辑之中没有必要使用一个额外的变 量z，它与变量y是完全相等的，因此我们可以使用y来代替z。
//复写传播的代码
public void foo() {
y = b.value;
// ...do stuff...
y = y;
sum = y + y;
}
- 优化四：无用代码消除(Dead Code Elimination)
//无用代码消除
public void foo() {
y = b.value;
// ...do stuff...
sum = y + y;
}
方法内联
例子里testInline()方法的内部全部是无用的代码，但如果不做内联，后续即使进行了无用代码消除的优化，也无法发现任何“Dead Code”的存在。如果分开来看，foo()和testInline()两个方法里面的操作都有可能是有意义的。
//未作任何优化的字节码
public static void foo(Object obj) {
if (obj != null) {
System.out.println("do something");
}
}
public static void testInline(String[] args) {
Object obj = null;
foo(obj);
}
Java对象的方法默认就是虚方法，为了解决虚方法的内联问题，引入了类型继承关系分析(Class Hierarchy Analysis，CHA)的技术，用于确定在目前已加载的类中，某个接口是否有多于一种的实现、某个类是否存在子类、某个子类是否覆盖了父类的某个虚方法等信息。如果是非虚方法，那么直接进行内联就可以了，这种的内联是有百分百安全保障的;如果遇到虚方法，则会向CHA查询此方法在当 前程序状态下是否真的有多个目标版本可供选择，如果查询到只有一个版本，那就可以假设“应用程序 的全貌就是现在运行的这个样子”来进行内联，这种内联被称为守护内联(Guarded Inlining)。由于Java程序是动态连接的，可能加载到新的类型改变CHA结论，因此这种内联属于激进预测性优化，必须预留好“逃生门”，即当假设条件不成立时的“退路”(Slow Path)。假如在程序的后续执行过程中，虚拟机一直没有加载到会令这个方法的接收者的继承关系发生变化的类，那这个内联优化的代码就可以一直使用下去。如果加载了导致继承关系发生变化的新类，那么就必须抛弃已经编译的代码，退回到解释状态进行执行，或者重新进行编译。
假如向CHA查询该方法存在多个版本的目标方法，那即时编译器还将进行最后一次努力，使用内联缓存(Inline Cache)的方式来缩减方法调用的开销。比起直接查虚方法表要快一些。内联缓存是一个建立在目标方法正常入口之前的缓存，它的工作原理大致为:在未发生方法调用之前，内联缓存状态为空，当第一次调用发生后，缓存记录下方法接收者的版本信息，并且每次进行方法调用时都比较接收者的版本。如果以后进来的每次调用的方法接收者版本都是一样的，那么这时它就是一种单态内联缓存(Monomorphic Inline Cache)。通过该缓存来调用，比用不内联的非虚方法调用，仅多了一次类型判断的开销而已。但如果真的出现方法接收者不一致的情况，就说明程序用到了虚方法的多态特性，这时候会退化成超多态内联缓存(Megamorphic Inline Cache)，其开销相当于真正查找虚方法表来进行方法分派。
逃逸分析
逃逸分析的基本原理是:分析对象动态作用域，当一个对象在方法里面被定义后，它可能被外部方法所引用。例如：
- 方法逃逸：作为调用参数传递到其他方法中
- 线程逃逸：被外部线程访问到，譬如赋值给可以在其他线程中访问的实例变量
从不逃逸、方法逃逸到线程逃逸，称为对象由低到高的不同逃逸程度。
对象不发生逃逸，则可能为这个对象实例采取不同程度的优化：
- 栈上分配(Stack Allocations):在Java虚拟机中，Java堆中的对象对于各个线程都是共享和可见的。虚拟机要回收不再使用的对象，会耗费大量的资源。如果确定对象不会逃逸出线程之外，那可以将对象在栈上分配内存，这样对象所占空间可随着栈帧出栈而销毁。栈上分配支持方法逃逸，不支持线程逃逸。
- 标量替换(Scalar Replacement):若一个数据无法再分解成更小的数据来表示了，Java虚拟机中的原始数据类型(int、long等数值类型及reference类型等)都不能再进一步分解了，那么这些数据就可以被称为标量。相反则称为聚合量(Aggregate)， Java 中的对象就是典型的聚合量。如果把一个Java对象拆散，根据程序访问的情况，将其用到的成员变量恢复为原始类型来访问，这个过程就称为标量替换。假如逃逸分析一个对象不会被方法外部访问，并且对象可以被拆散，那么程序真正执行时可能不去创建实例，而直接创建它的若干个被这个方法使用的成员变量来代替。将对象拆分后，除了可以让对象的成员变量在栈上(栈上存储的数据，很大机会被虚拟机分配至物理机器的高速寄存器中存储)分配和读写之外，还可以为后续进一步的优化手段创建条件。标量替换可以视作栈上分配的一种特例，实现更简单(不用考虑整个对象完整结构的分配)，但对逃逸程度的要求更高，它不允许对象逃逸出方法范围内。
- 同步消除(Synchronization Elimination):如果逃逸分析能够确定一个变量不会逃逸出线程，无法被其他线程访问，那么这个变量的读写肯定就不会有竞争， 对这个变量实施的同步措施也就可以安全地消除掉。
// 完全未优化的代码
//Point类的代码，这就是一个包含x和y坐标的POJO类型
public int test(int x) {
int xx = x + 2;
Point p = new Point(xx, 42);
return p.getX();
}
- 将Point的构造函数和getX()方法进行内联优化
// 步骤1:构造函数内联后的样子
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()被内联后的样子
}
- 经过逃逸分析，发现在整个test()方法的范围内Point对象实例不会发生任何程度的逃逸， 这样可以对它进行标量替换优化，把其内部的x和y直接置换出来，分解为test()方法内的局部变量，从 而避免Point对象实例被实际创建
// 步骤2:标量替换后的样子
public int test(int x) {
int xx = x + 2;
px = xx;
py = 42;
return px;
}
- 通过数据流分析，发现py 的值其实对方法不会造成任何影响，那就可以放心地去做无效代码消除得到最终优化结果。
// 步骤3:做无效代码消除后的样子
public int test(int x) {
return x + 2;
}
直到JDK7时这项优化才成为服务端编译器默认开启的选项。可以使用参数-XX:+DoEscapeAnalysis来手动开启逃逸分析，开启之后可通过参数-XX:+PrintEscapeAnalysis来查看分析结果。有了逃逸分析支持之后，使用参数-XX:+EliminateAllocations来开启标量替换，使用+XX:+EliminateLocks来开启同步消除，使用参数-XX:+PrintEliminateAllocations查看标量的替换情况。
公共子表达式消除
如果一个表达式E之前已经被计算过了，并且前后的E中所有变量的值都没有发生变化，那么E的这次出现就称为公共子表达式。对于这种表达式，只需要直接用前面计算过的表达式结果代替E。如果这种优化仅限于程序基本块内，便可称为局部公共子表达 式消除(Local Common Subexpression Elimination)，如果这种优化的范围涵盖了多个基本块，那就称为全局公共子表达式消除(Global Common Subexpression Elimination)
int d = (c * b) * 12 + a + (a + b * c);
iload_2 // b
imul // 计算b*c
bipush 12 // 推入12
imul //计算(c*b)*12
iload_1 //a
iadd //计算(c*b)*12+a
iload_1 //a
iload_2 //b
iload_3 //c
imul //计算b*c
iadd //计算a+b*c
iadd //计算(c*b)*12+a+a+b*c
istore 4
当这段代码进入虚拟机即时编译器后会被优化
//E = b*c
int d = E * 12 + a + (a + E);
//代数化简(Algebraic Simplification)优化
int d = E * 13 + a + a;
数组边界检查消除
数组边界检查消除(Array Bounds Checking Elimination)是即时编译器中的一项语言相关的经典优化技术。每次数组读写操作都带有一次隐含的条件判定操作，对大量的数组时，会影响性能。
数组foo[3]发生在循环中，并且使用了循环变量对数组进行访问。如果编译器要通过数据流分析就可以判定循环变量的取值范围永远在区间[0, foo.length)之内，则循环体中可以进行上下界检查消除掉。
源自书籍：深入理解Java虚拟机：JVM高级特性与最佳实践（第3版）-周志明
