晚期（运行期）优化（2）

编译过程

在默认设置下，无论是方法调用产生的即时编译请求，还是OSR编译请求，虚拟机在代码编译还未完成之前，都仍然将按照解释方式继续执行，而编译都做则在后台的编译线程中进行。一旦达到JIT的编译条件，执行线程向虚拟机提交编码请求后将会一直等待，直到编译过程完成后再开始执行编译器输出的本地代码。

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

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

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

最后阶段式在平台相关的后端使用线性扫描算法在LIR上分配寄存器，并在LIR上做窥孔优化，然后产生机器代码。

而Server Compiler则是专门面向服务端的典型应用并为服务端的性能配置特别调整过的编译器，也是一个充分优化过的高级编译器，几乎能达到GNU C++编译器使用-O2参数时的优化强度，它会执行所有经典的优化操作，如无用代码消除，循环展开，循环表达式外提，消除公共子表达式，常量传播，基本块重排序等，还会试试一些与Java语言特性密切相关的优化技术，如范围检查消除，空值检查消除，不过并非所有的空值检查消除都是依赖编译器优化的，有一些时在代码运行过程中自动优化了等。另外，还可能根据解释器或Client Compiler提供的性能控制信息，进行一些不稳定的激进优化，如守护内联，分支频率预测等。

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

编译优化技术

Java程序员有一个共识，以编译方式执行本地代码比解释方式更快，之所以有这样的共识，出去虚拟机解释执行字节码时额外消耗时间的原因外，还有一个很重要的原因就是虚拟机设计团队几乎把代码的所有优化措施都集中在了即时编译器之中，因此一般来说，即时编译产生的本地代码会比javac产生的字节码更加优秀。

优化技术概览

在Sun官方的Wiki上，HotSpot虚拟机设计团队列出了一个相对比较全面的，在即时编译器中采用的优化技术列表，其中有不少经典编译器的优化手段，也有许多针对Java语言（准确的说是针对运行在Java虚拟机上的所有语言）本身进行的优化技术。

即时编译器优化技术一览：

类型	优化技术
编译器策略	延迟编译
编译器策略	分层编译
编译器策略	栈上替换
编译器策略	延迟优化
编译器策略	程序依赖图表示
编译器策略	静态单赋值表示
基于性能监控的优化技术	乐观空值判断
基于性能监控的优化技术	乐观类型断言
基于性能监控的优化技术	乐观类型增强
基于性能监控的优化技术	乐观数组长度增强
基于性能监控的优化技术	裁剪未被选择的分支
基于性能监控的优化技术	乐观的多态内联
基于性能监控的优化技术	分支频率预测
基于性能监控的优化技术	调用频率预测
基于证据的优化技术	精准类型推断
基于证据的优化技术	内存值推断
基于证据的优化技术	内存值跟踪
基于证据的优化技术	常量折叠
基于证据的优化技术	重组
基于证据的优化技术	操作符退化
基于证据的优化技术	空值检查消除
基于证据的优化技术	代数化简
基于证据的优化技术	公共子表达式消除
数据流敏感重写	条件常量传播
数据流敏感重写	基于流承载的类型缩减转换
数据流敏感重写	无用代码消除
语言相关的优化技术	类型继承关系分析
语言相关的优化技术	去虚拟机化
语言相关的优化技术	符号常量传播
语言相关的优化技术	自动装箱消除
语言相关的优化技术	逃逸分析
语言相关的优化技术	锁消除
语言相关的优化技术	锁膨胀
语言相关的优化技术	消除反射
内存及代码位置变化	表达提升
内存及代码位置变化	表达式下沉
内存及代码位置变化	冗余存储消除
内存及代码位置变化	相邻存储合并
内存及代码位置变化	交汇点分离
循环变换	循环展开
循环变换	循环剥离
循环变换	安全点消除
循环变换	迭代范围分离
循环变换	范围检查消除
循环变换	循环向量化
全局代码调整	内联
全局代码调整	全局代码外提
全局代码调整	基于热度的代码布局
全局代码调整	Switch调整
控制流图变化	本地代码编排
控制流图变化	本地代码封包
控制流图变化	延迟槽填充
控制流图变化	着色图寄存器分配
控制流图变化	线性扫描寄存器分配
控制流图变化	复写聚合
控制流图变化	常量分裂
控制流图变化	复写移除
控制流图变化	地址模式匹配
控制流图变化	指令窥孔优化
控制流图变化	基于确定有限状态机的代码生成

公共子表达式消除

公共子表达式消除是一个普遍应用于各种编译器的经典优化技术，它的含义是：如果一个表达式E已经计算过了，并且从先前的计算到现在E中所有变量的值都没有发生变化，那么E的这次出现就成为了公共子表达式。对于这种表达式，没有必要花时间再对它进行计算，只需要直接用前面的计算过的表达式结果代替E就可以了。如果这种优化仅限于程序的基本块内，便称为局部公共子表达式消除，如果这种优化的范围涵盖了多个基本块，那就称为全局公共子表达式消除。举个简单的例子来说明以下，假设存在如下代码：
int d = (cb)12+a+(a+bc);
如果这段代码交给Javac编译器则不会进行任何优化。当这段代码进入到虚拟机即时编译器后，它将进行如下优化：编译器检测到“cb”与“bc”是一样的表达式，而且再计算期间b与c的值是不变的。因此，这条表达式可能被是为：
int d = E12+a+(a+E)；
这是，编译器还可能（取决于那种虚拟机的编译器及具体的上下文而定）进行另外一种优化：代数化简，把表达式变为：
int d = E13+a2;
表达式进行变化之后，在计算起来就可以节省一些时间了。

数组边界检查消除

数据边界检查消除是即时编译器中的一项语言相关的经典优化技术。Java中对数组的读写访问不像C，C++那样的本质上是裸指针操作。如果有一个数组foo[],在Java语言中访问数组元素foo[i]的时候系统将会自动进行上下界的范围检查，即检查i必须满足i>=0&&i<foo.length这个条件，否则将会抛出一个运行时异常：java.lang.ArrayIndexOutOfBoundsException。这对软件开发者来说是一件好事，即时程序员没有专门编写防御代码，也可以避免大部分的溢出攻击。但是对于虚拟机的执行子系统来说，每次数组元素的读写都带来了一次隐含的条件判定操作，对于用于大量数组访问的程序代码，这无疑也是一种性能负担。

无论如何，为了安全，数组边界检测肯定是必须做的，但数组边界检查是不是必须在运行期间一次不漏的检查则是可以“商量”的事情。将这个数组边界检查的例子放在更高的角度来看，大量的安全检查令Java程序比编写C/C++程序容易很多，如数组越界会得到java.lang.ArrayIndexOutOfBoundsException异常，空指针访问会得到NullPointException，除数为0会得到ArithmeticException等，在C/C++程序出现类似的问题，一不小心就会出现Segment Fault信号或者Window编程中常见的“XXX内存不能为Read/Write”之类的提示，处理不好程序就会直接崩溃退出了。但这些安全检查也导致了相同的程序，Java要比C/C++做更多的事情，这些事情就成为一种隐式开销，如果处理不好他们，就很可能成为一个Java语言比C/C++更慢的因素。要消除这些隐式开销，除了如数组边界检查优化这种尽可能把运行期检查提到编译器完成的思路之外，另外还有一种避免思路——隐式异常处理，Java中空指针检查和算术运算中除数为零的检查都采用了这种思路。

与语言相关的其他消除操作还有不少，如自动装箱消除，安全点消除，消除反射等。

方法内联

它是编译器最重要的优化手段之一，除了消除方法调用的成本之外，它更为重要的意义是为其他优化手段建立了良好的基础，方法内联的优化行为看起来很简单，不过是把目标方法的代码“复制”到发起调用的方法之中，避免发生真实的方法调用而已。但实际上Java虚拟机中的内联过程远远没有那么简单，因为如果不是即时编译器做了一些特别的努力，按照经典编译原理的优化理论，大多数的Java方法都无法进行内联。

由于Java语言提倡使用面向对象的编程方式进行编程，而Java对象的方法默认就是虚方法，因此Java间接鼓励了程序员使用大量的虚方法来完成程序逻辑。根据上面的分析，如果内联与虚方法之间产生“矛盾”，那么该怎么办呢？是不是为了提高执行性能，就要到处使用final关键字去修饰方法呢？

为了解决虚方法的内联问题，Java虚拟机设计团队想了很多的办法，首先是引入了一种名为“类型继承关系分析”的技术，这是一种基于整个应用程序的类型分析技术，它用于确定在目前已加载的类中，某个接口是否有对于一种的实现，某个类是否存在子类，子类是否为抽象类等信息。

编译器在进行内联时，如果是非虚方法，那么直接进行内联就可以了，这时候的内联是有稳定前期保障的。如果遇到虚方法，则会向CHA查询此方法在当前程序下是否有多个目标版本可供选择，如果查询结果只有一个本版，那就可以进行内联，不过这种内联就属于激进优化，需要预留一个“逃生门”，称为守护内联。如果程序的后续执行过程中，虚拟机一直没有加载到会令这个方法的接收者的继承关系发生变化的类，那这个内联优化的代码就可以一直使用下去。但如果加载了导致继承关系发生变化的新类，那就需要抛弃已经编译的代码，退回到解释状态执行，或者重新进行编译。

如果向CHA查询出来的结果有多个版本的目标方法可供选择，则编译器还会进行最后一次努力，使用内联缓存来完成方法内联，这是一个建立在目标方法正常入口之前的缓存，它的工作原理大致是：在未发生方法调用之前，内联缓存状态为空，当第一次调用发生后，缓存记录下方法接受者的版本信息，并且每次进行方法调用时都比较接受版本，如果以后进来的每次调用的方法调用者版本都是一样的，那这个内联还可以一直用下去。如果发生了方法接收者不一致的情况，就说明程序真正使用了虚方法的多态性，这是才会取消内联，查找虚方法表进行方法分派。

所以说，在许多情况下虚拟机进行的内联都是一种激进的优化，激进优化的手段在高性能的商用虚拟机中很常见，除了内联之外，对于出现概率很小的隐式异常，使用概率很小的分支等都可以被激进优化“移除”，如果真的出现了小概率事件，这是才会从“逃生门”回到解释状态重新执行。

逃逸分析

它与类型继承关系分析一样，并不是直接优化代码，而是为其他优化手段提供依据的分析技术。

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

如果能证明一个对象不会逃逸到方法或者线程之外，也就是别的方法或者线程无法通过任何途径访问到这个对象，则可能为这个变量进行一些高效的优化，如下：

• 栈上分配：Java虚拟机中，在Java堆上分配创建对象的内存空间几乎是Java程序都清楚的常识了，Java堆中的对象对于各个线程都是共享和可见的，只要持有这个对象的引用，就可以访问堆中存储的对象数据。虚拟机的垃圾收集系统可以回收堆中不再使用的对象，但回收动作无论是筛选可回收对象，还是回收和整理内存都需要耗费事件。如果确定一个对象不会逃逸出方法之外，那让这个对象再栈上分配内存将会是一个很不错的注意，对象所占用的内存空间可以随栈帧出栈而销毁。在一般应用中，不会逃逸的局部对象所占的比例很大，如果能使用栈上分配，那大量的对象就会随着方法的结束而自动销毁了，垃圾回收系统的压力将会小很多。
• 同步消除：线程同步本身是一个相对耗时的过程，如果逃逸分析能够确定一个变量不会逃逸除线程，无法被其他线程访问，那这个变量的读写肯定就不会有竞争，对这个变量实施的同步措施也就可以消除掉。
• 标量替换：标量是指一个数据已经无法再分解成更小的数据来表示了，Java虚拟机中的原始数据类型（int,long等数据类型以及referrence类型等）都不能再进一步分解，他们就可以称为标量。相对的，如果一个数据可以继续分解，那它就成为聚合量，Java中的对象就是最典型的聚合量。如果把一个Java对象拆散，根据程序访问的情况，将其使用到的成员变量恢复原始类型来访问就叫做标量替换。颗逃逸分析证明一个对象不会被外部访问，并且这个对象可以被拆散的话，那程序真正执行的时候将可能不创建这个对象，而改为直接创建它的若干个被这个方法使用到的成员变量来代替。将对象拆分后，除了可以让对象的成员变量在栈上（栈上存储的数据，有很大的概率会被虚拟机分配至物理机器的高速寄存器存储器中存储）分配和读取之外，还可以为后续进一步的优化手段创建条件。

关于逃逸的的论文在1999年就已经发表，但直到Sun JDK1.6才实现了逃逸分析，而且直到现在这项技术尚未足够程数，仍然有很大的改进余地。不成熟的原因是不能保证逃逸分析的性能收益必定高于它的消耗。如果要完成准确的判断一个对象是否会逃逸，需要进行数据流敏感的一系列复杂的分析，从而确定程序各个分支执行时对此对象的影响。这是一个相对高耗时的过程，如果分析完后发现没有几个不逃逸的对象，那这些运行期耗用的事件就白白浪费了，所以目前虚拟机智能采用不那么准确，但时间压力相对较小的算法来完成逃逸分析。还有一点，基于逃逸分析的一些优化手段，如上面提到的“栈上分配”，由于HotSpot虚拟机目前的实现方式导致栈上分配实现起来比较复杂，因此在HotSpot中暂时还没做这项优化。

尽管目前逃逸分析的技术仍然不是十分成熟，但是它确是即时编译器优化技术的一个重要的发展方向，在今后的虚拟机中，逃逸分析技术可能会支撑起一系列使用有效的优化技术。