程序编译与代码优化

编译器

• 前端编译器(或叫编译器前端):把.java文件转变为.class文件的过程,比如Sun的javac、Eclipse JDT中的ECJ
• 后端运行编译器(JIT编译器,Just In Time Compiler):把字节码转变为机器码的过程,比如HotSpot VM的C1、C2编译器
• 静态提前编译器(AOT编译器, Ahead Of Time Compiler):直接把*.java文件编译成本地机器代码的过程,比如GNU Compiler for the Java

1.早期(编译器)优化

1.1 概述

javac这类编译器对代码运行效率几乎没有任何优化措施,虚拟机设计团队把对性能的优化集中到了后端的即时编译器中,这样那些不是由javac产生的Class文件也同样能享受到编译器优化所带来的好处;但是javac做了许多针对Java语言编码过程的优化措施来改善程序员的编码风格和提高编码效率,相当多新生的Java语法特性,都是靠编译器的"语法糖"来实现,而不是依赖虚拟机的底层改进来支持;可以说,Java中即时编译器在运行期的优化过程对于程序运行来说更重要,而前端编译器在编译器的优化过程对于程序编码来说关系更加密切.

1.2 javac编译器

javac编译器本身就是一个由Java语言编写的程序,这为纯Java的程序员了解它的编译过程带来了很大的便利.

1.2.1 javac的源码与调试

javac的源码存放在JDK_SRC_HOME/langtools/src/share/classes/com/sun/tools/javac,除了JDK自身的API外,就只引用了JDK_SRC_HOME/langtools/src/share/classes/com/sun/*里面的代码; 导入javac的源码后就可以运行com.sun.tools.javac.Main的main方法来执行编译了.

javac编译过程大概可以分为3个过程

• 解析与填充符号表过程
• 插入式注解处理器的注解处理过程
• 分析与字节码生成过程

1.2.2 解析与填充符号表

1.词法,语法分析 解析步骤由parseFiles方法完成; 词法分析将源代码的字符流转变为标记(Token)集合,由com.sun.tools.javac.parser.Scanner类完成; 语法分析是根据Token序列构造抽象语法树(AST,一种用来描述程序代码语法结构的树形表示方式)的过程,由com.sun.tools.javac.parser.Parser类实现,AST由com.sun.tools.javac.tree.JCTree类表示;

2.填充符号表 由enterTrees方法完成;符号表是由一组符号地址和符号信息构成的表格,所登记的信息在编译的不同阶段都要用到,在语义分析中用于语义检查,在目标代码生成时用于地址分配;由com.sun.tools.javac.comp.Enter类实现;

1.2.3 注解处理器

在JDK 1.6中实现了JSR-269规范,提供了一组插入式注解处理器的标准API在编译期间对注解进行处理,可以读取、修改、添加抽象语法树中的任意元素. 通过插入式注解处理器实现的插件在功能上有很大的发挥空间,程序员可以使用插入式注解处理器来实现许多原本只能在编码中完成的事情; javac中,在initProcessAnnotations初始化,在processAnnotations执行,如果有新的注解处理器,通过com.sun.tools.javac.processing.JavacProcessingEnviroment类的doProcessing方法生成一个新的JavaCompiler对象对编译的后续步骤进行处理

1.2.4 语义分析与字节码生成

语义分析的主要任务是对结构上正确的源程序进行上下文有关性质的审查,主要包括

• 标注检查: 注入变量使用前是否已被声明,变量与赋值之间的数据类型是否能够匹配, 常量折叠
• 数据及控制流分析: 程序局部变量在使用前是否有赋值,方法的每条路径是否都有返回值,是否所有的受查异常都被正确处理.

解语法糖(Syntactic Sugar,添加的某种对语言功能没有影响但方便程序员使用的语法):Java中最常用的语法糖主要是泛型、变长参数、自动装箱等,他们在编译阶段还原回简单的基础语法结构;在com.sun.tools.javac.comp.TransTypes类和com.sun.tools.javac.comp.Lower类中完成

字节码生成:javac编译的最后一个阶段,不仅仅是把前面各个步骤所生成的信息转化为字节码写入到磁盘中,编译器还进行了少量的代码添加和转换工作(如实例构造器方法和类构造器方法);由com.sun.tools.javac.jvm.ClassWriter类的writeClass方法输出字节码,生成最终的Class文件.

1.3 Java语法糖的味道

1.3.1 泛型与类型擦除

Java语言的泛型只在程序源码中存在,在编译后的字节码文件中,就已经替换为原来的原生类型了,并且在相应的地方插入了强制转换,这种基于类型擦除的泛型实现是一种伪泛型. JCP组织引入了Signature属性,它的作用就是存储一个方法在字节码层面的特征签名,这个属性中保存的参数类型并不是原生类型,而是包括了参数化类型的信息.擦除法所谓的擦除,仅仅是对方法的Code属性中的字节码进行擦除,实际上元数据中还是保留了泛型信息,这样我们就可以通过反射手段获取参数化类型.

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

自动装箱,拆箱在编译之后就被转化成了对应的包装和还原方法,而遍历循环则把代码还原成了迭代器的实现.

1.33 条件编译

Java语言之中并没有使用预处理器,因为Java编译器并非一个个地编译Java文件,而是将所有编译单元的语法树顶级节点输入到待处理列表后再进行编译. Java语言可以使用条件为常量的if语句进行条件编译;编译器将会把分支中不成立的代码块消除掉.

1.34 实战:插入式注解处理器

实战目标:使用注解处理器API来编写一款拥有自己编码风格的校验工具. 代码实现:继承javax.annotation.processing.AbstractProcessor,实现process方法,从第一个参数annotations获取此注解处理器所要处理的注解集合,从第二个参数roundEnv中访问到当前这个Round中的语法树节点;另外还有一个很常用的实例变量processingEnv,它代表了注解处理器框架提供的一个上下文环境;可以配合使用的@SupportedAnnotationTypes和@SupportedSourceVersion注解;

@SupportedAnnotationTypes("*")
@SupportedSourceVersion(SourceVersion.RELEASE_6)
public class NameCheckProcessor extends AbstractProcessor{

    private NameChecker nameChecker;

    @Override
    public void init(ProcessingEnviroment processingEnv){
        super.init(processingEnv);
        nameChecker = new NameChecker(processingEnv);
    }

    @Override
    public boolean process(Set<? extends TypeElement> annotations, RoundEnviroment roundEnv){
        if(!roundEnv.processingOver){
            for(Element element : roundEnv.getRootElements()){
                nameChecker.checkNames(element);
            }
        }

        return false;
    }

}

2. 晚期(运行期)优化

2.1 概述

为了提高热点代码的执行效率,在运行时虚拟机将会把这些代码编译成与本地平台相关的机器码,并进行各种层次的优化,完成这个任务的编译器称为即时编译器(JIT). JIT不是虚拟机必需的,但是其编译性能的好坏、代码优化程度的高低却是衡量一款商用虚拟机优秀与否的最关键的指标之一,它也是虚拟机中最核心且最能体现虚拟机技术水平的部分.

2.2 HotSpot虚拟机内的即时编译器

2.2.1 解释器与编译器

当程序需要迅速启动和执行的时候,解释器可以先发挥作用,省去编译的时间立即执行;在程序运行后,随着时间的推移,编译器把越来越多的代码编译成本地代码提升执行效率.

HotSpot虚拟机中内置了两个即时编译器,分别为Client Compiler和Server Compiler,或简称为C1编译器和C2编译器;虚拟机会根据自身版本与宿主机器的硬件性能自动选择运行模式,也可以使用"-client"或"-server"参数去强制指定运行模式.

想要编译出优化程度更高的代码,解释器可能还要替编译器收集性能监控信息,为了在程序启动响应速度与运行效率之间达到最佳平衡,HotSpot虚拟机还会逐渐启动分层编译的策略:

• 第0层,程序解释运行,解释器不开启性能监控功能(Profiling),可触发第1层编译
• 第1层,C1编译,将字节码编译为本地代码,进行简单、可靠的优化,如有必要将加入性能监控的逻辑
• 第2层,C2编译,将字节码编译成本地代码,但是会启用一些编译耗时较长的优化,甚至会根据性能监控信息进行一些不可靠的激进优化

实施分层编译后,Client Compiler和Server Compiler将会同时工作,许多代码都可能会被多次编译,用Client Compiler获取更高的编译速度,用Server Compiler来获取更好的编译质量,在解释执行的时候也无须再承担性能收集监控信息的任务.

2.2.2 编译对象与触发条件

被JIT编译的热点代码有两类

• 被多次调用的方法: 编译器会以整个方法作为编译对象,属于标准的JIT编译方式
• 被多次执行的循环体: 尽管编译动作是由循环体所触发的,但编译器依然会以整个方法作为编译对象,这种编译方式称之为栈上替换(On Stack Replacement,OSR编译,即方法栈帧还在栈上,方法就被替换了)

热点探测

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

在HotSpot虚拟机中使用的是第二种,通过方法计数器(Invocation Counter)和回边计数器(Back Edge Counter)进行热点探测.

方法调用计数器 该计数器用于统计方法被调用的次数,他的默认阈值在Client模式下是1500次,在Server模式下是10000次,这个阈值可以通过虚拟机参数-XX:CompileThreshold来设定. 当一个方法被调用时,会先检查该方法是否存在被JIT编译过的版本,如果存在,则优先使用编译后的本地代码来执行.如果不存在,则将此方法的调用计数器加1,然后判断方法调用计数器与回边计数器值之和是否超过调用计数器的阈值.如果超过阈值,那么将会向即时编译器提交一个该方法的代码编译请求.如果不做任何设置,执行引擎并不会同步等待编译请求完成,而是继续进入解释器按照解释方式执行字节码.当编译工作完成之后,这个方法的调用入口地址就被系统自动改成新的,下一次调用该方法时就会使用已编译的版本.如果不做任何设置,方法调用计数器统计的不是方法被调用的绝对次数,当超过一定的时间限度,如果方法的调用次数依然不足以让他提交给即时编译器,那这个方法的调用计数器就会被减少一半,这称为热度衰减,而这段时间就称为半衰周期.可以使用虚拟机参数关闭热度衰减,或者设置半衰周期的时间.

方法调用计数器触发的即时编译交互过程如下图所示:

回边计数器 与方法调用计数器不同,回边计数器没有热度衰减,因此这个计数器统计的就是该方法循环执行的绝对次数. -XX:BackEdgeThreshold设置阈值(虚拟机没有用) -XX:OnStackReplacePercentage来间接调整回边计数器的阈值.

回边计数器阙值计算公式

• Client模式下: 阈值=方法调用计数器阈值*OnStackReplacePercentage/100(OnStackReplacePercentage默认值为933),都取默认值那么这个阈值为13995.
• Server模式下:阈值=(方法调用计数器阈值*OnStackReplacePercentage-InterpreterProfilePercentage)/100,其中OnStackReplacePercentage默认值为140,InterpreterProfilePercentage默认值为33, 结果阈值为10700

2.2.3 编译过程

对于Client Compiler来说,它是一个简单快速的三段式编译器,主要的关注点在于局部性的优化,而放弃了很多耗时较长的全局优化手段

• 第一阶段一个平台独立的前端将字节码构造成一个高级中间代码表示(HIR)
• 第二阶段一个平台相关的后端从HIR中产生低级中间代码表示(LIR)
• 最后阶段是在平台相关的后端使用线性扫描算法(Linear Scan Register Allocation)在LIR上分配寄存器,并在LIR上做窥孔(Peephole)优化,然后产生机器代码.

Server Compiler是专门面向服务端的典型应用并为服务端的性能配置特别调整过的编译器,也是一个充分优化过的高级编译器,几乎能达到GNU C++编译器使用-02参数时的优化强大,它会执行所有经典的优化动作,如无用代码消除、循环展开、循环表达式外提、消除公共子表达式、常量传播、基本块重排序等,还会实现如范围检查消除、空值检查消除等Java语言特性密切相关的优化技术;

2.2.4 查看及分析即时编译结果

本节的运行参数有一部分需要Debug或FastDebug版虚拟机的支持 要知道某个方法是否被编译过,可以使用参数-XX:+PrintCompilation要求虚拟机在即时编译时将被编译成本地代码的方法名称打印出来 还可以加上参数-XX:+PrintInlining要求虚拟机输出方法内联信息除了查看那些方法被编译之外,还可以进一步查看即时编译器生成的机器码内容,这个需要结合虚拟机提供的反汇编接口来阅读

2.3 编译优化技术

2.3.1 优化技术概览

• 公共子表达式消除: 如果一个表达式E已经计算过了,并且从先前的计算到现在E中所有变量的值都没有发生变化,那么E的这次出现就成为了公共子表达式,只需要直接用前面计算过的表达式结果代替E就可以了
• 数组边界检查消除(Array Bounds Checking Elimination): 对于虚拟机的执行子系统来说,每次数组元素的读写都带有一次隐含的条件判断,对于拥有大量数组访问的程序代码无疑是一种性能负担;
• 方法内联: 除了消除方法调用的成本外更重要的意义是为其他优化手段建立良好的基础; 为了解决虚方法的内联问题,引入了类型继承关系分析(CHA)技术和内联缓存(Inline Cache)来完成方法内联;
• 逃逸分析

2.3.1.1 逃逸分析

逃逸分析(Escape Analysis)并不是直接的优化手段,而是一个代码分析,通过动态分析对象的作用域,为其它优化手段如栈上分配、标量替换和同步消除等提供依据,发生逃逸行为的情况有两种:

• 方法逃逸:当一个对象在方法中定义之后,作为参数传递到其它方法中
• 线程逃逸:如类变量或实例变量,可能被其它线程访问到

如果能证明一个对象不会逃逸到方法或线程之外,则可能为这个变量进行一些高效的优化,比如栈上分配(减轻垃圾收集的压力)、同步消除(读写不会有竞争)、标量替换

同步消除 线程同步本身比较耗,如果确定一个对象不会逃逸出线程,无法被其它线程访问到,那该对象的读写就不会存在竞争,则可以消除对该对象的同步锁,通过-XX:+EliminateLocks可以开启同步消除.

标量替换

• 标量是指不可分割的量,如java中基本数据类型和reference类型,相对的一个数据可以继续分解,称为聚合量
• 如果把一个对象拆散,将其成员变量恢复到基本类型来访问就叫做标量替换
• 如果逃逸分析发现一个对象不会被外部访问,并且该对象可以被拆散,那么经过优化之后,并不直接生成该对象,而是在栈上创建若干个成员变量

通过-XX:+EliminateAllocations可以开启标量替换, -XX:+PrintEliminateAllocations查看标量替换情况.

栈上分配 故名思议就是在栈上分配对象,其实目前Hotspot并没有实现真正意义上的栈上分配,实际上是标量替换.

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

Java虚拟机的即时编译器与C/C++的静态优化编译器相比,可能会由于下列这些原因而导致输出的本地代码有一些劣势:即时编译器运行占用用户程序运行时间、动态类型安全语言导致的频繁检查、运行时对方法接收者进行多态选择的频率大、可以动态扩展导致很多全局的优化难以运行、大部分对象在堆上分配导致垃圾收集机制的效率低 Java语言的特性换取了开发效率的提升、还有许多优化是静态优化编译器不好做的,比如别名分析、还有一些以运行期性能监控为基础的优化措施如调用频率预测等