Skip to content

Latest commit

 

History

History
533 lines (463 loc) · 48.2 KB

程序编译与代码优化.md

File metadata and controls

533 lines (463 loc) · 48.2 KB
Raw

程序编译与代码优化

早期（编译期）优化

Java语言的“编译期”是一段“不确定的操作过程

  • 前端编译器：把*.java文件转变为*.class文件

  • 后端运行编译器：把字节码转变为机器码的过程（JIT）

  • 静态提前编译器：直接把*.java文件编译成本地机器码的过程（AOT）

  • 前端编译器：Sun的Javac、Eclipse JDT中的增量式编译器（ECJ）

  • JIT编译器：HotSpot VM的C1、C2编译器

  • AOT编译器：GCJ、Excelsior JET

Javac编译器对代码的运行效率几乎没有任何优化措施（JDK1.3后，Javac的-O优化参数就不再有意义），但Javac做了许多针对Java语言编码过程的优化措施来改善程序员的编码风格和提高编码效率 虚拟机设计团队把对性能的优化集中到了后端的即时编译器中（这样可以让不是由Javac产生的Class文件同样能享受到编译器优化带来的好处） 前端编译器在编译器的优化过程对程序编码来说关系密切，后端运行编译器对程序运行更为重要

Javac编译器

HotSpot虚拟机使用C++语言实现（少量C语言）

Javac编译器由Java语言编写

Javac的源码与调试

虚拟机规范严格定义了Class文件的格式，但是《Java虚拟机规范（第2版）》中，没有对如何把Java源文件代码转变为Class文件的编译过程进行十分严格的定义 Class文件编译在某种程度上与具体JDK实现相关

Javac编译过程

  1. 解析与填充符号表过程
  2. 插入式注解处理器的注解处理过程
  3. 分析与字节码生成过程
![编译过程](D:\local\notes\images\javac-compile.bmp)
![编译过程主体代码](D:\local\notes\images\javac-code.bmp)

解析与填充符号表

parseFiles()：解析步骤包括了词法分析和语法分析两个过程

词法、语法分析

词法分析是将源代码的字符流转变为标记（Token）集合，单个字符是程序编写过程的最小元素，而标记则是编译过程的最小元素，关键字、变量名、字面量、运算符都可以成为标记 在Javac源码中，词法分析过程由com.sun.tools.javac.parser.Scanner类来实现

语法分析是根据Token序列构造抽象语法树的过程 抽象语法树是一种用来描述程序代码语法结构的树形表示方式，语法树的每一个节点都代表着程序代码中的一个语法结构（例如包、类型、修饰符、运算符、接口、返回值甚至代码注释等都可以是一个语法结构） 在Javac的源码中，语法分析过程由com.sun.tools.javac.parser.Parser类实现，这个阶段产出的AST由com.sun.tools.javac.tree.JCTree 经过这个步骤后，编译器基本不会再对源码文件进行操作了，后续的操作都建立在抽象语法树上 抽象语法树结构视图

填充符号表

在Javac源码中，enterTrees()负责填充符号表，填充符号表的过程由com.sun.tools.javac.comp.Enter类实现，此过程的出口是一个待处理列表，包含了每一个编译单元的AST的顶级节点，以及package-info.java（如果存在的话）的顶级节点 符号表是由一组符号地址和符号信息构成的表格 符号表不一定是哈希表实现，可以是有序符号表、树状符号表、栈结构符号表等，符号表所登记的信息在编译的不同阶段都要用到

  • 在语义分析中，符号表所登记的内容将用于语义检测（如检查一个名字的使用和原先的说明是否一致）和产生中间代码
  • 在目标代码生成阶段，当对符号表进行地址分配时，符号表是地址分配的依据

注解处理器

JDK1.5后，Java语言提供了对注解支持，这些注解与普通Java代码一样，在运行期发挥作用 JDK1.6实现了JSR-269规范，提供了一组插入式注解处理器的标准API在编译器对注解进行处理（可以把它看做是一组编译器的插件） 在这些插件里，可以读取、修改、添加抽象语法树的任意元素 如果这些插件在处理注解期间对语法树进行了修改，编译器将回到解析及填充符号表的过程重新处理，指到所有插入式注解处理器都没有再都语法树进行修改，每一次循环称为一个Round 在Javac源码中，插入式注解处理器的初始化过程是在initProcessAnnotations()方法中完成的，而它的执行过程则是在processAnnotations()方法中完成的，这个方法判断是否还有新的注解处理器需要执行，如果有的话，通过com.sun.tools.javac.processing.JavacProcessingEnvironment类的doProcessing()方法生成一个新的JavaCompiler对象对编译的后续步骤进行处理

语义分析与字节码生成

AST能够表示一个结构正确的源程序的抽象，但无法保证源程序是符合逻辑的 语义分析的主要任务是对结构上正确的源程序进行上下文有关性质的审查，如进行类型审查 注：是否符合语义逻辑必须限定在具体的语言与具体的上下文环境中才有意义

标注检查

Javac的编译过程，语义分析系过程分为标注检查以及数据及控制流分析，分别有attribute()和flow()方法完成

标注检查的内容

  1. 变量使用前是否被声明
  2. 变量与赋值间的数据类型是否能够匹配
注：标注检查步骤中有一个重要的动作称为常量折叠
`int a = 1 + 2`
![常量折叠](D:\local\notes\images\constant-fold.bmp)
标注检查步骤在Javac源码中的实现类是com.sun.tools.javac.comp.Attr类和com.sun.tools.javac.comp.Check类
数据及控制流分析

数据及控制流分析是对程序上下文逻辑更进一步的验证

  1. 程序局部变量使用前是否赋值
  2. 方法的每条路径是否都有返回值
  3. 是否所有的受查异常都被正确处理了
编译期的数据及控制流分析与类加载时的数据及控制流分析的目的基本一致，但校验范围有所区别，有一些检验项只有在编译期或运行期才能进行。

final语义校验

//方法一带有final修饰
public void foo(final int arg) {
  final int var = 0;
  //do something
}
//方法二没有final修饰
public void foo(int arg) {
   int var = 0;
   //do something
}

这两段代码编译出来的Class文件没有一点区别

局部变量与字段的区别

  1. 局部变量在常量池中没有CONSTANT_Fieldref_info的符号引用（自然就没有访问标志Access_Flags的信息）
  2. 局部变量可能连名称都不会保留下来（取决于编译时选项）
自然在Class文件中不可能指导一个局部变量是否声明为FInal了，因此将局部变量声明为final对运行期没有影响，变量的不变性由编译器在编译期保障
在Javac的源码中，数据及控制流分析的入口是flow()方法，具体操作由com.sun.tools.javac.comp.Flow类来完成
解语法糖

语法糖，也称糖衣语法，是由英国计算机科学家彼得·约翰·兰达发明的一个术语 语法糖指计算机语言中添加某种语法对语言的功能没有影响，但更方便程序员使用 语法糖能够增加程序的可读性，从而减少程序代码出错的机会

Java在现代编程语言中属于“低糖语言”（相对于C#及许多其他JVM语言来说） Java中最常用的语法糖主要是泛型（泛型不一定都是语法糖实现，C#的泛型是由直接CLR支持的）、变长参数、自动装箱/拆箱

虚拟机在运行时不支持这些语法，它们在编译阶段还原回简单的基础语法结构，这个过程称为解语法糖 在Javac的源码中，解语法糖的过程由desugar()方法触发，在com.sun.tools.javac.comp.TransTypes类和com.sun.tools.javac.comp.Lower类中完成

字节码生成

字节码生成是Javac编译过程的最后一个阶段，在Javac源码里面有com.sun.tools.javac.jvm.Gen类来完成 字节码生成阶段不仅把前面各个步骤生成的信息（语法树、符号表）转化成字节码写到磁盘中，编译器还进行了少量的代码添加和转换工作 例如，实例构造器()和类构造器()方法就是在这个阶段添加到语法树中的 注：这里的实例构造器并不是指默认构造函数，如果用户代码中没有提供任何构造函数，那编译器将会添加一个没有参数的、访问性与当前类一致的默认构造函数，这个工作在填充符号表阶段就已经完成 注：这两个构造器的产生构成实际上是一个代码收敛的过程，编译器会把语句块（实例构造器是“{}”块，类构造器是“static{}”块、变量初始化（实例变量和类变量）、调用父类的实例构造器-仅仅是实例构造器，()方法中无须调用父类的()方法，虚拟机会自动保证父类构造器执行，但在()方法中经常会生成调用java.lang.Object的()方法的代码）等操作收敛到()和()方法中，并且保证一定是先执行父类实例构造器，然后初始化变量，最后执行语句块 上述动作有Gen.normalizeDefs()方法实现

除了生成构造器以外，还有一些代码替换工作用语优化程序的实现逻辑 字符串的家操作替换为StringBuffer或StringBuilder（取决于目标代码的版本是否大于或等于JDK1.5）的append()操作

完成了对语法树的遍历和调整后，就会把填充了所有所需信息的符号表交个com.sun.tools.javac.jvm.ClassWriter类，由这个类的writeClass()方法输出字节码，生成最终的Class文件

Java语法糖的味道

语法糖（编译器“小把戏”）

  • 优点
    1. 或能提高效率
    2. 或能提升语法严谨性
    3. 或能减少编码出错的机会
  • 缺点
    1. 程序员产生依赖
    2. 无法看清语法糖的糖衣背后，程序代码的真实面目

泛型与类型擦除

泛型本质是参数化类型的应用，也就是操作的数据类型被指定为一个参数。 这种参数类型可以用在类、接口和方法的创建中，分别称为泛型类、泛型接口和泛型方法 泛型思想早在C++语言的模板中就开始生根发芽，在Java语言还没出现泛型的版本时，只能通过Object是所有类型的父类和类型强制转换两个特点的配合来实现类型泛化（Object转型成任何对象都是有可能的，因为无限可能性，只有程序员和运行期的虚拟机才知道这个Object到底是个什么类型的对象，编译期间，编译器无法检查这个Object的强制转型是否成功，如果仅仅依赖程序员去保障这项操作的正确性，许多ClassCastException的风险就会转嫁到程序运行期）

C#与Java中的泛型技术（实现上本质不同）

  • C#泛型无论在程序源码中、编译后的IL中（中间语言，这时泛型是一个占位符），或是运行期的CLR中都是切实存在的，List与List就是两个不同的类型，它们在系统运行期生成，有自己的虚方法表和类型数据，这种实现称为类型膨胀，基于这种方法实现的泛型称为真实泛型
  • Java语言中的泛型只在程序源码中存在，在编译后的字节码文件中，就已经替换为原来的原生类型（也称为裸类型）了，并且在相应的地方插入了强制转型代码，对运行期的Java语言来说，ArrayList与ArrayList就是同一个类，所以泛型技术实际上是Java语言的一颗语法糖，Java语言中的泛型实现方法称为类型擦除，基于这种方法实现的泛型称为伪泛型

伪泛型

  1. 部分人认为强制转型操作和运行期缺少针对类型的优化导致比C#的泛型慢一些
  2. 作者认为选择从性能角度上评价用于提升语义准确性的泛型思想不太恰当

通过擦触法来实现泛型丧失了一些泛型思想该有的优雅

  • 泛型遇见重载1--类型擦除成相同原生类型导致无法重载（无法重载部分原因）
public GenericTypes{
    public static void method(List<String> list) {
        System.out.println("invoke method(List<String> list)");
    public static void method(List<Integer> list) {
        System.out.println("invoke method(List<Integer>List)")
    }
    }
}
  • 泛型遇见重载2
public class GenericTypes{
   public static String method(List<String> list) {
        System.out.println("invoke method(List<String> list)");
       return "";
   }
    public static int method(List<Integer> list) {
        System.out.println("invoke method(List<Integer>List)");
        return 1;
    }
    public static void main(String[] args) {
        method(new ArrayList<String>());
        method(new ArrayList<Integer>);
    }
}
//可以编译并执行

注：Java语言中返回值不参与重载，但在Class文件格式中，只要描述符不是完全一致的两个方法就可以共存

JCP组织对虚拟机规范做出了修改（泛型引入，各种场景-虚拟机解析、反射等下的方法调用都可能对原有基础常识影响和新的需求，如在泛型类中如何获取传入的参数化类型等），引入诸如Signature、LocalVariableTypeTable等新的属性用于解决伴随泛型而来的参数类型的识别问题 Signature是其中最重要的一项属性，存储一个方法在字节码层面的特征签名（方法独一无二且不可重复的ID），Java代码方法签名：方法名称、参数顺序及参数类型；字节码方法签名：还包括方法返回值及受查异常表。这个属性中保存的参数类型不是原生类型，而是包括了参数化类型的信息 注：擦除法仅仅对方法Code属性中的字节码进行擦除，实际元数据中还保留了泛型信息，这是能通过反射手段取得参数化类型的根本依据

自动装箱、拆箱与遍历循环

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

自动装箱的陷阱 包装类的"=="运算在不遇到算术运算的情况下不会自动拆箱，以及它们equals方法不处理数据转型 注：包装类型比较最好使用equals并且进行同类型比较

条件编译

C、C++使用预处理器指示符（#ifdef）来完成条件编译，它们的预处理器最初的任务是解决编译时的代码依赖关系（如#include预处理命令） Java语言的编译方式-编译器并非一个个地编译Java文件，而是将所有编译单元的语法树顶级节点输入到待处理列表后再进行编译，因此各个文件之间能够互相提供符号信息，无须使用预处理器

Java条件编译（也是语法糖） 使用条件为常量的if语句（如果使用常量与其他带有条件判断能力的语句搭配，则可能在控制流分析中提示错误，被拒绝编译） 根据布尔常量值的真假，编译器将把分支中不成立的代码块消除掉，这一工作在编译器解除语法糖阶段完成 注：这种方式必须遵循最基本的Java语法，只能写在方法体内部，因此只能实现语句基本块级别的条件编译，而没有办法实现根据调整整个Java类的结构

其他语法糖：内部类、枚举类、断言语句、对枚举和字符串（在JDK1.7中支持）的switch支持、try语句中第一和关闭资源（在JDK1.7中支持）等

实战：插入式注解处理器

一套编程语言中编译子系统的优劣，很大程度决定了程序运行性能的好坏和编码效率的高低

实战目标

编译器把Java程序源码编译为字节码时，会对Java程序源码各方面检查校验（主要以程序”写得对不对“，较少校验程序”写得好不好“）

程序“写得好不好”辅助校验工具

  • CheckStyle
  • FindBug
  • Klocwork 这些代码校验工具有一些基于Java源码进行校验，还有一些是通过扫描字节码来完成

目标：使用注解处理器API来编写一款拥有自己编码风格的校验工具：NameCheckProcessor 《Java语言规范（第3版）》中第6.8节要求，Java程序命名规范

  • 类（或接口）：符合陀式命名法，首字母大写
  • 方法：符合驼式命名法，首字母小写
  • 字段
    • 类或实例变量：符合驼式命名法，首字母小写
    • 常量：要求全部由大写字母或下划线构成，并且第一个字符不能是下划线

代码实现

  1. 继承抽象类javax.annotation.processing.AbstractProcessor
  2. 覆盖抽象方法：process()-它是Javac编译器在执行注解处理器代码时要调用的过程
  3. 该方法第一个参数annotations获取此注解处理器所要处理的注解集合
  4. 第二个参数roundEnv访问到当前这个Round中语法树的节点，每个语法树节点在这表示为一个Element
  5. 除了process()方法传入的参数外还有很常用的实例变量processingEnv，它是AbstractProcessor中的一个protected变量，在注解处理器初始化的时候创建，它代表了注解处理器框架提供的一个上下文环境，要创建新的代码、向编译器输出信息、获取其他工具类等都需要用到这个实例变量
  6. 注解处理器除了process()方法及其参数外，还有两个可以配合使用的Annotations：@SupportedAnnotationTypes和@SupportedSourceVersion，前者代表这个注解处理器对那些注解感兴趣，可使用“*”作为通配符代表对所有注解都感兴趣，后者支持这个注解处理器可以处理哪些版本的Java代码

Element（JDK1.6javax.lang.model） Java代码中最常用的元素：包（PACKAGE）、枚举（ENUM）、类（CLASS）、注解（ANNOTATION_TYPE）、接口（INTERFACE）、枚举值（ENUM_CANSTANT）、字段（FIELD）、参数（PARAMETER）、本地变量（LOCAL_VARIABLE）、异常（EXCEPTION_PARAMETER）、方法（METHOD）、构造函数（CONSTRUCTOR）、静态语句块（STATIC_INIT）、实例语句块（INSTATNCE_INIT）、参数化类型（TYPE_PARAMETER）和未定义的其他语法树节点（OTHER）

注：每个注解处理器运行时都是单例的 注：如果不需要改变或生成语法树的内容，process()方法可以返回false，通知编译器这个Round中代码未发生变化，无须构造新的JavaCompiler实例

运行与测试

通过Javac命令的-processor参数来执行编译时需要附待的注解处理器，如果有多个，用逗号分隔。还可使用-XprintRounds和-XprintProcessorInfo参数来查看注解处理器运作的详细信息

其他应用案例

JSR-269嵌入式注解处理器API还有用于校验Hibernate标签使用正确性的Hibernate Validator Annotation Processor、自动为字段生成getter和setter方法的项目lombok（根据已有元素生成新的语法树）

晚期（运行期）优化

编译优化技术

Java程序员共识：编译方式执行本地代码比解释方式更快

  • 虚拟机解释执行字节码时额外消耗时间
  • 虚拟机团队几乎把对代码的所有优化措施都集中在JIT中（在JDK1.3后，Javac就去除了-O选项，不会生成任何字节码级别的优化代码了） 一般来说，JIT产生的本地大妈比Javac产生的字节码更优秀（由编译器优化得到的本地机器码与由解释器解释字节码后实际执行的本地代码之间的对比） ###概述 部分商用虚拟机（Sun HotSpot、IBMJ9）中，Java程序最初是通过解释器进行解释执行，当虚拟机发现某个方法或代码块的运行特别频繁时，就会把这些代码认定为“热点代码”。 为了提高热点代码执行效率，在运行时虚拟机会使用JIT将这些代码编译器成本地平台相关的机器码，并进行各种层次的优化

即时编译器并不是虚拟机必需的部分，Java虚拟机规范并没有规定Java虚拟机内必须要有即时编译器存在，更没有限定或指导即时编译器应该如何实现 即时编译器编译性能的好坏、代码优化程度地高低是衡量一款商用虚拟机优秀与否的最关键指标之一（它是虚拟机中最核心且最能体现虚拟机技术水平的部分）

HotSpot虚拟机内的即时编译器

  1. 为何HotSpot虚拟机要是用解释器与编译器并存的架构？
  2. 为何HotSpot虚拟机要实现两个不同的即时编译器？
  3. 程序何时使用解释器执行？何时使用编译器执行？
  4. 哪些程序代码会被编译为本地代码？如何编译为本地代码？
  5. 如何从外部观察即时编译器的编译过程和编译结果？

解释器与编译器

并不是所有Java虚拟机都采用解释器与编译器并存的架构（JRockit内部没有解释器，一次会存在“启动响应时间长”，主要面向服务端--这类应用一般不关注启动时间）

解释器

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

解释器与编译器配合工作

HotSpot虚拟机内置两个即时编译器分别称为Client Compiler和Server Compiler（C1编译器和C2编译器-也叫Opto编译器） 目前主流HotSpot虚拟机（Sun系列JDK1.7及之前的版本的虚拟机）中，默认采用解释器与其中一个编译器直接配合的方式工作，程序使用哪个编译器，取决于虚拟机的运行模式，HotSpot虚拟机会根据自身版本与宿主机器的硬件性能自动选择运行模式（用户可使用-client或-server参数强制指定虚拟机运行在Client模式或Server模式） 注：无论采用的编译器是C1还是C2，解释器与编译器搭配使用的方式在虚拟机中称为“混合模式”（用户可以使用参数-Xint强制虚拟机运行于解释模式，也可以使用参数-Xcomp强制虚拟机运行于编译模式--前者编译器完全不介入工作，全部代码使用解释方式执行；后者有限采用编译方式执行程序，但解释器仍然要在编译无法进行的情况下接入执行过程） 注：可以使用虚拟机的-version命令输出显示这三种模式

分层编译（权衡程序启动响应速度与运行效率）

  1. 编译器编译本地代码需要占用程序运行时间，要编译出优化程度更高的代码，所花费的时间可能更长
  2. 要编译出优化程度更高的代码，解释器可能还要替编译器收集性能监控信息，对解释执行的速度也有影响
注：分成编译的概念在JDK1.6时期出现，一直处于改进阶段，最终在JDK1.7的Server模式虚拟机中作为默认编译策略被开启

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

  1. 第0层，程序解释执行，解释器不开启性能监控功能，可触发第1层编译
  2. 第1层，也称C1编译，将字节码编译为本地代码，进行简单、可靠的优化，如有必要加入性能监控逻辑
  3. 第2层（或第2层以上），也称C2编译，也是将字节am编译为本地代码，但是会启用一些编译耗时较长的优化，甚至会根据性能监控信息进行一些不可靠的激进优化
注：实施分层编译后，Client Compiler和Server Compiler将会同时工作，许多代码都可能被多次编译，用C1编译器获取更高的编译速度，用C2编译器获取更好地编译质量，在解释执行的时候也无须再承担收集性能监控信息（编译依据）的任务

编译对象与触发条件

热点代码（被即时编译器编译）

  • 被多次调用的方法

    整个方法作为编译对象（这种编译时虚拟机中标准的JIT编译方式）

  • 被多次执行的循环体（解决一个方法制备调用一次或少量几次，但方法体内部存在循环次数较多的循环体问题）

    尽管编译动作由循环体触发，但编译器仍然以整个方法作为编译对象 这种编译方式因为编译发生在方法执行过程中，因此信息地称为栈上替换简称OSR编译，即方法栈帧还在栈上，方法就被替换了

热点探测（最近流行-基于踪迹的热点探测） 判断一段代码是不是热点代码，是不是需要触发即时编译

  1. 基于采样的热点探测：采用这种方法的虚拟机会周期性检查各个线程的栈顶，如果发型某个（或某些）方法经常出现在栈顶，那这个方法就是“热点探测”
    • 基于采样的热点探测好处是是实现简单、高效，可以很容易获取方法调用关系（展开调用堆栈）
    • 缺点是很难精确地确认一个方法的热度，容易因为受到线程阻塞或别的外界因素的影响而扰乱热点探测
  2. 基于计数器的热点探测：采用这种方法的虚拟机会为每个方法（甚至是代码块）建立计数器，统计方法的执行次数，如果执行次数超过一定阈值就认为它是“热点方法”
    • 这种方法实现起来麻烦一些，需要为每个方法建立并维护计数器，而且不能直接获取到方法调用关系
    • 这种方法统计结果相对来说更加精确和严谨

注：HotSpot虚拟机使用的是第二种-基于计数器的热点探测方法（它为每个方法准备了两类计数器：方法调用计数器和回边计数器） 注：在虚拟机运行参数确定前提下，这两个计数器都有一个确定的阈值，当计数器超过阈值溢出了，就会触发JIT编译 注：进行热点探测不一定要知道方法具体被调用了多少次

方法调用计数器 目的：统计方法被调用次数 Client模式下默认阈值1500次；Server模式下10000次 这个阈值可以通过虚拟机参数-XX:compileThreshold来认为设定 注：当一个方法被调用时，会先检查该方法是否存在被JIT编译过得版本，如果存在，则优先使用编译后的本地代码来执行。如果该不存在已经被编译过得版本，则将此方法的调用计数器值加1，然后判断方法调用计数器与回边计数器之和是否超过方法调用计数器的阈值。如果已经超过阈值，将向编译器提交一个该方法的代码编译请求 注：如果不做任何设置，执行引擎不会同步等待编译请求完成，而是继续进入解释器按照解释方式执行代码，直到提交的请求被编译器编译完成（当编译工作完成后，这个方法的调用入口地址会被系统自动改写成新的，下一次调用该方法时就会使用已编译的版本） JIT编译交互过程 注：如果不做任何设置，方法调用计数器统计的并不是方法被调用的绝对次数，二三十一个相对的执行频率（一段时间内方法被调用的次数） 注：当超过一定的时间限度，如果方法调用次数仍然不足以让它提交给即时编译器编译，那这个方法的调用计数器就会被减少一半-这个过程称为方法调用计数器热度的衰减；这段时间称为此方法计数器的半衰周期 注：进行热度衰减动作是在虚拟机进行垃圾收集时顺便进行的，可以使用虚拟机参数-XX:-UserCounterDecay来关闭热度衰减，让方法计数器统计方法调用的绝对次数（只要系统运行时间足够长，绝大部分方法都会被编译成本地代码） 注：可以使用-XX:CounterHalfLifeTime参数设置半衰周期，单位是秒

回边计数器 目的：统计一个方法中循环体代码执行的次数，触发OSR编译 回边：在字节码中遇到控制流向后跳转的指令称为“回边”（空循环，不会被回边计数器统计） HotSpot虚拟机提供了-XX:BackEdgeThreshold（当前虚拟机并未使用此参数），因此需要设置另外一个参数-XX:OnStackReplacePercentage来间接调整回边计数器阈值

计算公式 虚拟机运行在Client模式下：方法调用计数器阈值OSR比率/100 其中OnStackReplacePercentage默认值为933，如果都取默认值，那Client模式虚拟机回边计数器阈值为13995 虚拟机运行在Server模式西：方法调用计数器阈值（OSR比率-解释器监控比率）/100 其中OnStackReplacePercentage默认值为140，InterpreterProilePercentage默认值为33，那Server模式虚拟机回边计数器阈值为10700

当解释器遇到一条回边指令时，会先查找将要执行的代码片段是否已有编译好的版本，如果有，优先执行已编译的代码，否则回边计数器加1，然后判断方法调用计数器与回边计数器之和是否超过回边计数器阈值，当超过阈值时，将提交一个OSR编译请求，并且把回边计数器值降低一些，以便在解释器中执行循环，等待编译器输出编译结果 执行过程 注：回边计数器没有计数热度衰减过程（这个计数器统计的就是该方法循环执行的绝对次数） 注：当计数器溢出时，它还会把方法计数器的值也调整到溢出状态，这样下次再进入该方法时就会执行标准编译过程 注：以上两图仅描述了Client VM的即时编译方式，对于ServerVM来说，执行情况会更复杂 Java方法虚拟机内存布局 注：一行长度32位

编译过程

在默认设置下，无论是方法调用产生的即时编译请求，还是OSR编译请求，虚拟机在代码编译器还未完成前，都仍然按照解释方式继续执行，而编译动作则在后台的编译线程中进行 用户可以通过参数-XX:-BackgroundCompilation来禁止后台编译（在禁止后台编译后，一旦达到JIT的编译条件，执行线程向虚拟机提交编译请求后将会一直等待，直到编译过程完成后再开始执行编译器输出的本地代码）

Client Compiler编译过程

  • C1编译器是一个简单快速的三段式编译器
  • 主要的关注点在于局部性的优化，而放弃了许多耗时较长的全局优化手段
    1. 在第一个阶段，一个平台独立的前端将字节码构造成一种高级中间代码表示HIR，HIR使用静态单分配SSA的形式来代表代码值，这可以使得一些在HIR构造过程中和后很小的优化动作更容易实现（在此之前编译器会在字节码上完成一部分基础优化，如方法内联、常量传播等优化会在字节码被构造成HIR之前完成）
    2. 在第二阶段，一个平台相关的后端从HIR中产生低级中间代码表示LIR，而在此之前会在HIR上完成另外一些优化（如空值检查消除、范围检查消除等，以便让HIR达到更高效的代码表示形式）
    3. 最后阶段是在平台相关的后端使用线性扫描算法在LIR上分配寄存器，并在LIR上做窥孔优化，然后产生机器代码 C1编译过程

Server Compiler编译过程 C2编译器是专门面向服务端的典型应用并为服务端性能配置特别调整过的编译器，也是一个充分优化过得高级编译器，几乎能达到GNU C++编译器使用-O2参数时的优化强度 C2编译器会执行所有经典优化动作，如无用代码消除、循环展开、循环表达式外提、消除公共子表达式、常量传播、基本块重排序等还会实施一些与Java语言特性密切相关的优化技术，如范围检查消除、空值检查消除（不过并非所有空值检查消除都是依赖编译器优化的，有一些是在代码运行过程中自动优化了）等，另外还可能根据解释器或C1编译器提供的性能监控信息，进行一些不稳定的激进优化，如守护内联、分支频率预测等 Server Compiler的寄存器分配器是一个全局着色分配器，它可以充分利用某些处理器架构（如RISC）上的大寄存器集合 以即时编译的标准来看，C2编译器是比较缓慢的，但它的编译速度依然远远超过传统的静态优化编译器，而且它相对于C1编译器输出的代码质量有所提高，可以减少本地代码的执行时间，从而抵消了额外的编译时间开销，所以也有很多非服务端应用选择使用Server模式的虚拟机运行

查看及分析即时编译结果

虚拟机提供了一些参数用来输出即时编译和某些优化手段（如方法内联）的执行情况 部分运行参数需要Debug或FastDebug版虚拟机支持

示例代码

public static final int NUM = 15000;
public static int doubleValue(int i) {
  for (int j = 0 ; j< 100000 ; j++);
  return i * 2;
}
public static long calcSum() {
  long sum = 0;
  for (int i = 1 ; i <= 100 ; i++) {
      sum += doubleValue(i)
  }
  return sum;
}
public static void main(String[] args) {
  for (int i = 0 ; i < NUM ; i++) {
      calcSum();
  }
}

要知道某个方法是否被编译过，可以使用参数-XX:PrintCompilation要求虚拟机在即时编译时将被编译成本地代码的方法名称打印出来（带有%的输出说明是由回边计数器触发的OSR编译） 使用参数-XX:+PrintInlining要求虚拟机输出方法内联信息

除了查看哪些方法被编译外，还可以进一步查看即时编译器生成的机器码内容，机器码必须反汇编成基本的汇编语言才能别阅读 虚拟提供了一组通用的反汇编接口，可以介入各种平台下的反汇编适配器来使用（如使用32位80x86平台则选用hsdis-i386适配器，其余平台的适配器还有hsdis-amd64、hsdis-sparc和hsdis-sparcv9等，可以下载或自己编译出反汇编适配器，然后放置在JRE/bin/client或/server目录下，只要与jvm.dll的路径相同即可被虚拟机调用） 虚拟机安装了反汇编适配器后可以使用-XX:+PrintAssembly参数要求虚拟机打印编译方法的汇编代码（如果没有HSDIS插件支持，也可以使用-XX:+PrintOptoAssembly-用于Server VM 或-XX:+PrintLIR-用于Clent VM 来输出比较接近最终结果的中间代码表示） 注：-XX：+PrintAssembly参数需要Debug或FastDebug版的虚拟机支持，如果使用Product版的虚拟机，需要加入参数-XX:+UnlockDiagnosticVMOptions打开虚拟机诊断模式

如果出了本地代码生成结果外，还想进一步跟踪本地代码生成的具体过程，还可以使用参数-XX:+PrintCFGToFile（使用Client Compiler)或-XX：PrintIdealGraphFile（使用Server Compiler）令虚拟机将编译过程中各个阶段的数据（如，对C1编译器来说，包括字节码、HIR生成、LIR生成、寄存器分配过程、本地代码生成等数据）输出到文件中，然后使用Java HotSpot Client Compiler Visualizer（用于分析ClientCompiler）或Ideal Graph Visualizer（用于分析ServerCompiler）打开这些数据文件进行分析

ServerCompiler的中间代码表示是一种名为Ideal的SSA形式程序依赖图 注：执行空循环会占用CPU时间（如果没有任何优化） 注：Java语言定义的安全需要（如类型安全、空指针检查）和Java虚拟机的运作需要（如Safepoint轮询）以及一行语句可能形成好几个基本块（如循环）导致方法按基本块划分后形成的图形结构复杂

忽略语言安全检查基本块，doubleValue()方法执行了以下几件事

  1. 程序入口，建立栈帧
  2. 设置j=0，进行Safepoint轮询，跳转到4的条件检查
  3. 执行j++
  4. 条件检查，如果j<100000，跳转到3
  5. 设置i = i*2，进行Safepoint轮询，函数返回
注：看空循环是否优化，或何时优化，只要观察代表循环的基本块是否消除，或何时消除
注：输出CFG或IdealGraph文件，需要一个Debug版胡FastDebuf版的虚拟机支持，Product版的虚拟机无法输出这些文件

优化技术概览（HotSpot）

优化技术列表有不少经典编译器的优化手段，也有许多针对Java语言（准确地说是针对运行在Java虚拟机上的所有语言）本身进行的优化技术 JIT编译器优化技术列表 JIT编译器优化技术列表1 这些代码优化变换是建立在代码的某种中间表示或机器码之上，绝不是建立在Java源码上的

方法内联

  • 去除方法调用的成本（如建立栈帧）
  • 为其他优化建立良好的基础，方法内联膨胀之后可以便于在更大范围上采取后续的优化手段，从而获取更好地优化效果 注：方法内联的重要性高于其他优化措施，各种编译器一般都会把内联优化放在优化序列的最靠前位置

冗余访问消除

public void foo() {
  y = b.value;
  //do stuff
  z = b.value;
  sum = y + z;
}
public void foo() {
  y = b.value;
  //do stuff
  z= y;
  sum = y + z;
}

假设do stuff不会改变b.value的值，那么可以把z = b.value替换为z = y，这样可以不再去访问对象b的成员变量 注：如果把b.value看做一个表达式，那可以把这项优化看成是公共子表达式消除

复写传播

public void foo() {
  y = b.value;
  //do stuff
  y = y;
  sum = y + y
}

变量z与变量y完全相等，因此可以使用y来代替z

无用代码消除

public void foo() {
  y = b.value;
  //do stuff
  sum = y + y;
}

无用代码可能是永远不会被执行的代码，也可能是完全没有意义的代码（Dead code）

公用子表达式消除

公用子表达式是一个经典优化技术 含义：如果一个表达式E已经计算过了，并且从先前的计算到现在E中所有变量值都没有发生变化，那么E的这次出现就成了公用子表达式，对于这种表达式，没有必要花时间再对它进行计算，只需要直接用前面计算过的表达式结果代替E就可以了 局部公共子表达式消除：这种优化仅限于程序基本块内 全局公用字表达式消除：优化范围涵盖多个基本块 编译器在进行公用字表达式消除时还可能（取决于哪种虚拟机的编译器及具体上下文而定）进行代数化简

数组边界检查消除

数组边界检查消除是即时编译器一项语言相关的经典优化技术 Java语言是一门动态安全的语言（数组越界检查、空指针访问检查、除数为零检查等），对数组的读写不像C、C++（Segment Fault信号或“xxx内存不能访问”）那样本质上是裸指针操作 如果有一个数组foo[]，在Java语言中访问数组元素时系统将自动进行上下界的范围检查，如果越界则抛出一个运行时异常：java.lang.ArrayIndexOutOfBoundsException（可以避免大部分溢出攻击） 注：对虚拟机执行子系统来说，每次数组元素的读写都带有一次隐含的条件判定操作，对于拥有大量数组访问的程序代码，是一种性能负担

为了安全，数组边界检查必须做，但是不必一次不漏（编译器根据数据流分析可以判断下标没有越界或者数组访问发生在循环中且使用循环变量进行数组访问数据流分析循环变量取值范围不越界就可以把数组上下界检查消除）

Java语言的安全检查导致隐式开销，消除隐式开销

  1. 数组边界检查优化尽可能把运行期检查提到编译期完成
  2. 隐式异常处理-Java中空指针检查和算术运算中除数为零

    虚拟机会注册一个Segment Fault信号的异常处理器（伪代码中的uncommon_trap()），这样当foo不为空时，对value的访问不会额外消耗一次对foo判空的开销 代价是当foo为空时，必须转入到异常处理器中恢复并抛出NullPointExcption异常，这个过程必须从用户态转到内核态中处理，结束后再回到用户态，速度远比一次判空检查慢 当foo极少为空时，隐式异常优化是值得的，但假如foo经常为空的话，这样的优化反而会让程序更慢（HotSpot虚拟机可以根据运行期收集到的Profile信息自动选择最优方案）

  3. 与语言相关的其他消除操作还有不少，如自动装箱消除、安全点消除、消除反射等
if (foo != null) {
   return foo.value;
} else {
   throw new NullPiontException();
}

try {
   return foo.value;
} catch (segment_fault) {
   uncomon_trap();
}

方法内联

方法内联的优化行为不过是把目标方法的代码“复制”到发起调用的方法中，避免发生真实的方法调用，但实际上Java虚拟机中的内联过程远远没有那么简单（如果不是编译器做了一些特别努力，按经典编译原理的优化理论，大多数Java方法都无法内联）

无法内联的原因

  • 只有使用invokespecial以及invokestatic调用的方法是在编译期进行解析
  • 除了上述方法之外，其他Java方法的调用都需要在运行时进行方法接收者的多态选择，并且都可能存在多于一个版本的方法接收者
  • 最多再除去被final修饰的方法，尽管它使用invokevirtual指令调用，但也是非虚方法 注：对于一个虚方法，编译器做内联时根本无法确定应该使用哪个方法版本

解决虚方法内联

  1. 类型继承关系分析CHA
    • 这是一种基于整个应用程序的类型分析技术
    • 它用于确定在目前已加载的类中，某个接口是否有多于一种实现，某个类是否存在子类、子类是否为抽象类等信息
    • 编译器在进行内联时，如果是非虚方法，直接进行内联即可（此时内联时有稳定前提保障的）
    • 如果是虚方法，则向CHA查询此方法在当前程序下是否有多个目标版本可以选择，如果查询结果自由一个版本也可进行内联，不过这种内联属于激进优化，需要预留一个“逃生门”（Guard条件不成立时的Slow Path），称为守护内联
    • 如果程序后续执行过程中虚拟机一致没有加载到会令这个方法的接收者的继承关系发生变化的类，那这个内联优化的代码就可以一致使用下去，但如果加载了导致继承关系发生变化的新类，那需要抛弃已经编译的代码，退回到解释状态执行，或者重新编译
    • 如果想CHA查询出来的结果又多个版本的目标方法可供选择，则编译器还将会进行最后一次努力，使用内联缓存来完成方法内联，这是一个建立在目标方法正常入口之前的缓存
    • 内联缓存工作原理：在未发生方法调用前，内联缓存状态为空，当第一次调用发生后，缓存记录下方法接收者的版本信息，并且每次进行方法调用时都比较接收者版本，如果以后进来的每次调用的方法接收者版本一致，那么这个内联还可以一致使用；如发生了方法接收者不一致的情况，说明程序真正使用了虚方法的多态特性，这是才会取消内联，查找虚方法表进行方法分派 注：许多情况下虚拟机进行的内联都是一种激进优化，激进优化的手段在高性能的商用虚拟机中很常见，除了内联之外，对于出现概率很小（通过经验数据或解释器收集到的性能监控信息确定概率大小）的隐式异常、使用概率很小的分支都可以被激进优化“移除”，如果出现了小概率事件，这时才会从“逃生门”回到解释状态重新执行

逃逸分析（默认不开启）

逃逸分析与类型继承关系分析一样，并不是直接优化代码的手段，而是为其他优化手段提供依据的分析技术 基本行为：分析对象动态作用域，当一个对象在方法中被定义后，它可能被外部方法引用（如作为调用参数传递到其他方法中，称为方法逃逸；甚至可能被外部线程访问到，譬如赋值给类变量或可以在其他线程中反问的实例变量，称为线程逃逸）

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

  • 栈上分配（HotSpot虚拟机暂时还没有做）
    • Java堆中对象对于各个线程都是共享和可见的，只要持有这个对象的引用，就可以反问堆中存储的对象数据
    • 虚拟机的垃圾回收系统可以回收堆中不再使用的对象，但无论是筛选可回收对象，还是回收和整理内存都需要耗费时间
    • 如果确定一个对象不会逃逸出方法之外，那么这个对象在栈上分配内存，对象占用的内存空间可以随栈帧出栈销毁
    • 使用栈上分配，垃圾收集系统的压力会小很多
  • 同步消除
    • 线程同步本身是一个相对耗时的工作
    • 如果逃逸分析能够确定一个变量不会逃逸出线程，无法被其他线程访问，那这个变量的读写不会有竞争，对这个变量实施的同步措施也就可以消除掉
  • 标量替换
    • 标量指一个数据已经无法再分解成更小的数据来表示
    • Java虚拟机中的原始数据类型（int.long等数值类型记忆reference类型等）不能再进一步分解，可以成为标量
    • 聚合量指一个数据可以继续分解（Java对象典型的聚合量）
    • 标量替换指把一个Java对象拆散，根据程序访问的情况，将其使用到的成员变量恢复原始类型来访问
    • 如果逃逸分析证明一个对象不会被外部访问，且该对象可以被拆散，那程序执行时可能不创建这个对象，而改为直接创建它的若干个被这个方法使用到的成员变量来代替
    • 将对象拆分后，除了可以让对象的成员变量在栈上（栈上存储的数据，有很大概率会被虚拟机分配至物理机器的高速寄存器存储）分配和读写外，还可以为后续进一步优化手段创建条件 注：逃逸分析在Sun JDK1.6实现，但尚未成熟（不能保证性能受益必定高于消耗） 注：可以使用参数-XX:+DoEscapeAnalysis手动开启逃逸分析系，开启后可以通过参数-XX:+PrintEscapeAnalysis查看分析结果；有了逃逸分析支持后，可以使用参数-XX:+EliminateAllocations开启标量替换，使用-XX:+EliminateLocks开启同步消除，使用参数-XX:+PrintEliminateAllocations查看标量替换情况

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

  1. JIT运行占用用户程序运行时间，具有很大时间压力，它能提供的优化手段也严重受制于编译成本
  2. Java语言是动态类型安全语言，意味着需要虚拟机确保程序不会违反语言语义或反问非结构化内存
  3. Java没有virtual关键字，但是使用虚方法频率远远大于C/C++语言
  4. Java语言动态扩展语言，运行时加载新的类可能改变程序类型的继承关系，使得很多全局优化难以进行
  5. Java语言对象内存分配都是在堆上进行，只有方法中局部变量栈上分配
  6. 在C/C++中，别名分析难度远高于Java（Java类型安全），别名分析决定了许多数据依赖相关优化进行（重排序、变量代换）
  7. Java在运行期性能监控为基础进行的优化措施C/C++都无法进行（如调用频率预测、分支频率预测、裁剪未被选择的分支等）