JVM编译与运行优化

发表于 | 分类于

编译期优化

对性能的优化集中在后端的即时编译器，这样可以让那些不是由javac产生的class文件也能同样享受到编译器优化带来的好处。前端编译期的优化主要用于改善程序员的编码风格和提高编码效率。相当多的Java语法特性，都是靠编译器的“语法糖”（也称糖衣语法，指在计算机语言中添加的某种语法，对功能没有影响，但是能增加程序的可读性和提升编码效率，减少程序代码出错的机会）来实现。

泛型与类型擦除

泛型是JDK1.5开始提供的一项新特性，本质是参数化类型，也就是说所操作的类型被指定为一个参数。参数类型可以用于类、接口和方法，分别称为泛型类、泛型接口和泛型方法。

泛型技术在C#中是切实存在的，List<int>和List<String>就是两个不同的类型，在运行期产生，有自己的虚方法表和类型数据，这种实现称为类型膨胀，基于这种方法实现的泛型称为真实泛型。而Java中的泛型只在源码中存在，编译后的字节码文件中就已经被替换为原来的原生类型，然后再相应的地方插入强制类型转换代码，因此，在运行期，List<int>和List<String>是同一个类型。Java中的泛型实现称为类型擦除，基于这种方法实现的泛型称为伪泛型。

引入Signature属性，存储一个方法在字节码层面的特征签名，用于识别传入的参数化类型，这个属性中保存的参数类型并不是原生类型，而是包含了参数化类型信息。类型擦除，仅仅是对方法的Code属性中的字节码进行擦除，实际上元数据中还保留了泛型信息，因此，能通过反射手段取得参数化类型。

自动装箱、拆箱、遍历循环、变长参数

自动装箱、拆箱在编译后被转化成了对应的包装和还原方法，如：Integer.valueOf()与Integer.intValue()方法，而遍历循环则是把代码还原成了迭代器的实现，这也是为何遍历循环需要被遍历的类实现Iterable接口的原因。变长参数，在调用的时候变成了一个数组类型的参数。

插入式注解处理器API

实现注解处理器需要继承抽象类javax.annotation.processing.AbstractProcessor，覆盖唯一一个abstract方法：

1
public boolean process(Set<? extedns TypeElement> annotations, RoundEnvironment roundEnv);

该方法是javac编译器在执行注解处理器代码时要调用的过程。可以从第二个参数roundEnv中访问到当前这个round中的语法树节点，每个树节点在这里表示为一个Element。返回false表示不需要改变或生成语法树的内容。通过继承javax.lang.model.util.ElementScanner6.NameCheckScanner以Visitor模式来完成对语法树的遍历。

javac通过指定-processor参数在执行编译时设置自定义的注解处理器（如果有多个注解处理器，以逗号分隔），即可以在javac编译过程中插入对源码的自定义检查逻辑。

运行期优化

当JVM发现某个方法或者代码块的运行特别频繁，就会将这些代码认定为“热点代码”（Hot Spot Code），为了提高热点代码的运行效率，在运行时，虚拟机将会把这些代码编译成与本地平台相关的机器码，并进行各种层次的优化，完成这个任务的编译器成为即时编译器（Just In Time Compiler，JIT）。

在运行期动态编译可能比C/C++静态编译的代码更优秀，因为运行期可以收集很多静态编译器无法知道的信息，甚至可以采用很激进的优化手段，在优化条件不成立的时候在逆优化退回来。所以只要Java代码没有问题，随着代码被编译得越来越彻底，运行速度应当越来越快。运行时编译的缺点是编译需要消耗程序正常运行时间，也就是“编译时间”。

解释器与编译器选择

解释器与编译器各有优势：

  • 当程序需要迅速启动和执行的时候，解释器可以首先发挥作用，省去编译的时间，立即执行。当程序运行后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码后，可以获取更高的执行效率。
  • 当程序运行环境中内存资源限制较大（如部分嵌入式系统），可以使用解释执行节约内存，繁殖可以使用编译执行来提升效率。
  • 解释器可以作为编译器激进优化时的一个“逃生门”，让编译器根据概率选择一些大多数时候能提升运行速度的优化手段，当激进优化假设不成立，如加载了新类后类型继承机构出现变化、出现“罕见陷阱”（Uncommon Trap）时可以通过逆优化退回到解释状态继续执行。

HotSpot JVM内置了两个即时编译器：Client Compiler和Server Compiler，简称C1编译器和C2编译器。默认是采用解释器和其中一个编译器直接配合的方式工作，程序使用哪个编译器，取决于JVM运行模式。JVM会根据自身版本与宿主机器的硬件性能自动选择运行模式，用户也可以使用-client或-server参数强制指定运行模式。

默认解释器与编译器搭配使用的方式称为“混合模式”（Mixed Mode），用户可以使用参数-Xint强制指定运行于“解释模式”（Interpreted Mode），全部使用解释方式执行，或者-Xcomp强制指定运行于“编译模式”（Compiled Mode），这时优先采用编译方式执行，但解释器仍要在编译无法进行的情况下。

由于JIT编译本地代码需要占用程序运行时间，要编译出优化程度更高的代码，花费的时间可能更长；而且，解释器可能还要替编译器收集性能监控信息，这对解释执行的速度也有所影响。为了在程序启动响应速度和运行效率之间达到最佳平衡，HotSpot JVM启用分层编译（Tiered Compilation）的策略。根据编译器编译、优化的规模与耗时，划分三个编译层次：0层，解释执行，不开启性能监控；C1编译，简单可靠的优化；C2编译，编译耗时较长的优化，甚至会根据性能监控信息进行一些不可靠的激进优化。分层编译后，Client Compiler和Server Compiler将同时工作，代码可能会被多次编译，用Client Compiler获取更高的编译速度，用Server Compiler获取更好的编译质量，在0层解释执行的时候也无需再承担收集性能监控信息的任务。

编译触发条件

被多次调用的方法，或者方法只被调用少量，但是内部存在循环次数较多的循环体被重复执行多次，会被认为是“热点代码”。都会以整个方法作为编译对象，对于循环体需要编译整个方法，因为编译发生在执行过程中，被称为栈上替换（On Stack Replacement，OSR）。要知道一段代码是否热点代码，称为热点探测（Hot Spot Detection），方式有两种：

  • 基于采样的热点探测：周期性检查各个线程的栈顶，如果发现某些方法经常出现在栈顶，就是“热点方法”。优点是：实现简单高效，容易获取调用关系，缺点是难以精确确认热度，容易受到线程阻塞或外界因素影响
  • 基于计数器的热点探测：为每个方法（甚至代码块）建立计数器，统计方法的执行次数，超过一定的阈值就认为是“热点方法”。实现麻烦一些，需要每个方法计数器，不能获取方法调用关系。优点是统计结果精确。

HotSpot JVM采用基于计数器的热点探测，为每个方法设置两个计数器：调用计数器（Invocation Counter）和回边计数器（Back Edge Counter）。

调用计数器统计方法被调用的次数，默认阈值：Client模式下1500次，Server模式下10000次，可以通过-XX:CompileThreshold设定。默认设置下，调用计数器统计的不是被调用的绝对次数，而是相对的执行频率。当超过一定时间限度，如果调用次数仍然不足以提交给JIT编译，则调用计数器会被减少一半，称为热度衰减（Counter Decay），这段时间称为半衰周期（Counter Half Life Time）这个动作是在JVM进行GC的时候顺便进行的，可以设置-XX:-UseCounterDecay来关闭热端衰减，从而使用绝对次数，这样，只要运行时间足够长，绝大部分方法都会被编译成本地代码。通过-XX:CounterHalfLifeTime设置半衰周期时间，单位是秒。

回边计数器，统计方法中循环体（回边）执行的次数，在字节码中遇到控制流往后跳转的指令称为“回边”，通过-XX:OnStackReplacePercentage来间接设定。Client模式，OnStackReplacePercentage=933，回边计数器阈值：13995，Server模式，OnStackReplacePercentage=140，回边计数器阈值：10700。回边计数器没有计数热度衰减过程，因此统计的是循环执行的绝对次数。当计数器溢出的时候，会把调用计数器的值也设置为溢出状态，这样下次再调用该方法就会执行标准编译过程。

编译过程

通过-XX:-BackgroundCompilation禁止后台编译，当达到JIT编译条件，执行线程会一直等待，直到编译过程完成再开始执行编译器输出的本地代码。

Server Compiler和Client Compiler两个编译器编译过程不一样。Client Compiler是一个快速的三段式编译器，主要关注点是局部的优化，放弃了许多耗时较长的全局优化手段。

  1. 平台独立的前端将字节码构造成一种高级中间代码表示（High-Level Intermediate Representation，HIR）。使用静态单分配（Static Single Assignment，SSA）的形式来代表代码值，可以使得一些在HIR构造过程之中和之后进行的优化动作更容易实现。在此之前编译器会在字节码上完成一部分基础优化，如：方法内联（最重要的优化手段，为其他优化手段建立良好基础）、常量传递等优化将会在字节码被构造成HIR之前完成
  2. 平台相关的后端从HIR中产生低级中间代码表示（Low-Level Intermediate Representation，LIR），在此之前会在HIR上完成另外一些优化，如：空值检查消除、范围检查消除等，以便让HIR达到更高效的代码表示形式
  3. 在平台相关的后端使用线性扫描算法（linear Scan Register Allocation）在LIR上分配寄存器，并在LIR上做窥孔（Peephole）优化，然后产生机器代码。

Server Compiler是一个充分优化过的高级编译器，几乎能达到GNU C++编译器使用-O2参数时的优化强度。Server Compiler的寄存器分配器是一个全局图着色分配器，可以充分利用某些处理器架构（如RISC）上的大寄存器集合。

  • 语言无关的经典优化：公共子表达式消除（如果表达式的所有变量都没有变化，这个表达式再次出现时无需重新计算）
  • 与Java语言特性密切相关的优化：数组范围检查消除（根据数据流分析确定数组边界，如果判定下标没有越界，执行时无需进行数组边界检查）
  • 根据解释器或者Client Compiler提供的性能监控信息，进行一些不稳定的激进优化：
    • 守护内联：Guarded Inlining，为了解决虚方法在运行时才能确定版本的问题，引入“类型继承关系分析”（Class Hierarchy Analysis，CHA），对于虚方法，如果目前加载的类只有一个版本，则可以内联，但是属于激进优化，需要预留逃生门，称为守护内联，如果后续执行中加载了导致继承关系变化的新类，就需要抛弃已经编译的代码，退回解释状态执行，或者重新进行编译；如果查询出来有多个版本，使用内联缓存（Inline Cache）来完成方法内联，第一次调用时，缓存记录方法接收者的版本信息，然后每次方法调用都比较接收者版本，如果以后的版本都一样，这个内联可以一直用下去，如果发生了方法接收者不一致，会取消内联，查找虚方法进行方法分派
    • 分支频率预测：Branch Frequency Prediction，对于出现概率很小的隐式异常和分支都可以被激进优化移除掉，如果真的出现小概率事件，才会从逃生门回到解释状态重新执行
    • 逃逸分析：Escape Analysis，分析对象动态作用域：一个对象在方法里面定义，可能被外部方法引用。如：作为调用参数传递到其他方法，称为方法逃逸；被外部线程访问（赋值给类变量或可以在其他线程访问的实例变量），称为线程逃逸。如果能证明一个对象不会逃逸，则可以为这个变量进行一些高效优化：栈上分配（Stack Allocations，分配在栈上，减少GC压力）；同步消除（Synchronization Elimination）；标量替换（Scalar Replacement，不创建对象，改为直接创建它的若干个被这个方法使用的成员变量）。判断对象是否逃逸，需要进行数据流敏感的复杂分析，是一个相对高耗时的过程。

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

  • JIT占用用户运行时间，如果编译速度不能达到要求，用户将会察觉重大延迟，限制了JIT不能随便引入大规模优化技术。而编译时间成本在静态编译器中不是主要关注点
  • Java是动态类型安全语言，需要JVM频繁进行动态检查：空指针、数组元素越界等，尽管编译器会进行优化，但总体仍然要消耗不少运行时间
  • Java使用虚方法频率远远大于C/C++，意味着运行时多态选择频率更高，因此优化（如：方法内联）是难度更大
  • Java是动态扩展语言，运行时加载新的类可以改变程序的继承关系，使得全局的优化难以进行，许多全局优化只能以激进优化方式来完成
  • Java不定期GC带来的性能影响，C/C++由用户回收内存，不存在无用对象筛选
  • JIT能做，静态编译器不能做的优化：以运行期性能监控为基础的优化措施，如调用频率预测、分支频率预测、裁剪未被选择的分支等