从计算机程序出现的第一天起,对效率的追求就是程序天生的坚定信仰,这个过程犹如一场没有终点,永不停歇的F1方程式竞赛,程序员是车手,技术平台则是赛道上飞驰的赛车.
java语言的"编译期"其实是一段"不确定"的操作过程,因为它可能是一个前端编译器(编译器的前端)把*.java文件转变成*.class文件的过程;也可能是指虚拟机的后端运行期编译器(JIT编译器)把字节码转变为机器码的过程;还可能是使用静态提前编译器(AOT编译器)直接把*.java文件编译成本地机器代码的过程.
前端编译器:把java文件转变成class文件
后端运行期编译器:把字节码转变为机器码
静态提前编译器:把java文件转变为机器码
这三类编译过程的一些代表编译器:
前端编译器:Sun的javac. Eclipse JDT中的增量式编译器(ECJ)
JIT编译器:HotSpot VM 的C1,C2编译器
AOT编译器:GUN GCJ,Excelsior JET
虚拟机设计团队把对性能的优化集中到了后端的即时编译器中
java中即时编译器在运行期的优化过程对于程序运行来说更重要,而前端编译器在编译期的优化过程对于程序编码来关系更加密切.
javac编译器本身是一个由纯java语言编写的程序
HotSpot虚拟机使用C++和少量C实现
javac编译器的编译过程大致可以分为3个过程,分别是:
解析和填充符号表过程
1.解析步骤包括词法分析和语法分析
2.填充符号表步骤
注解处理器
语义分析和字节码生成过程
语义分析过程分为标注检查以及数据及控制流分析两个步骤
字节码生成
字节码生成阶段不仅仅是把上述步骤所生成的信息转化成字节码写到磁盘中,编译器还进行了少量的代码添加和转化工作.如实例构造器
当泛型遇见重载:擦除动作导致方法的特征签名变得一模一样.
java的一些其他语法糖:内部类.枚举类,断言语句(assert),对枚举和字符串的switch支持,try语句中的定义和关闭资源等.
虚拟机参数:
开启断言:-ea
关闭断言:-da
以上就是javac前端编译器的优化内容与过程.
在HotSpot虚拟机中,java程序最初是通过解释器进行解释执行的,当虚拟机发现某个方法或代码块的运行特别频繁时,就会把这些代码认定为"热点代码".为了提高热点代码的执行效率,在运行时虚拟机将会把这些代码编译成和本地平台相关的机器码,并进行各种层次的优化,完成这个任务的编译器称为即时编译器(JIT编译器).
HotSpot虚拟机中同时包含解释器和编译器.两者各有优势:当程序需要迅速启动和执行的时候,解释器可以首先发挥作用,省去编译的时间,立即执行.在程序运行后,随着时间的推移,编译器逐渐发挥作用,把越来越多的代码编译成本地代码之后,可以获得更高的执行效率.同时,解释器还可以作为编译器激进优化时的一个"逃生门".让编译器根据概率选择一些大多数时候都能提升运行速度的优化手段,当激进优化的假设不成立时可以通过逆优化退回到解释状态继续执行(部分没有解释器的虚拟机中也会使用不进行激进优化的C1编译器担任"逃生门"的角色),因此整个虚拟机执行架构中,解释器与编译器经常配合工作.
HotSpot虚拟机中内置了两个即时编译器,默认采用解释器和其中一个编译器直接配合的方式工作,使用哪个编译器,取决于虚拟机运行的模式.
Client Compiler称为C1=========C1不进行激进优化
Server Compiler称为C2
虚拟机参数:
强制运行在Client模式:-client
强制运行在Server模式:-server
因为client模式不支持64位,所以64位jvm不能用client模式启动
解释器与编译器搭配使用的方式在虚拟机中称为"混合模式"(Mixed Mode)
编译器完全不介入工作,代码全部使用解释方式执行的方式称为"解释模式"(Interpreted Mode)
优先采用编译方式执行程序,但是解释器仍然要在编译无法进行的情况下介入执行过程的方式称为"编译模式"(Compiled Mode)
虚拟机参数:
查看版本及运行模式:-version
强制运行在解释模式:-Xint
强制运行在编译模式:-Xcomp
即时编译器编译本地代码需要占用程序运行时间,要编译出优化程度更高的代码,所花费的时间可能更长;而且想要编译出优化程度更高的代码,解释器可能还要替编译器收集性能监控信息,这对解释执行的速度也会有影响.
JDK1.7以后默认开启分层编译,分层编译根据编译器编译,优化的规模与耗时,划分出不同的编译层次:
第0层:程序解释执行,解释器不开启性能监控功能,可触发第1层编译.
第1层:也称为C1编译,将字节码编译为本地代码,进行简单,可靠的优化,如有必要将加入性能监控的逻辑.
第2层(或2层以上):也称为C2编译,也是将字节码编译为本地代码,但是会启用一些编译耗时较长的优化,甚至会根据性能监控信息进行一些不可靠的激进优化.
实施分层编译后Client Compiler和Server Compiler将会同时工作,用Client Compiler获取更高的编译速度,用Server Compiler获取更好的编译质量,在解释执行的时候也无须再承担性能监控信息的任务.
在运行过程中会被即时编译器编译的"热点代码"有两类,即:
被多次调用的方法.
被多次执行的循环体.
第一种:方法调用触发的编译,JIT编译器以整个方法体作为编译对象.
第二种:循环体触发的编译,JIT编译器以整个方法体作为编译对象.
第两种方式因为编译发生在方法执行过程之中,因此形象地称之为栈上替换(OSR编译),即方法栈帧还在栈上,方法就被替换了.
判断一段代码是不是热点代码,是否需要触发即时编译,这样的行为称为热点探测,主流的有两种:
HotSpot虚拟机采用的是基于计数器的热点探测方法,它为每个方法准备了两类计数器:方法调用计数器和回边计数器,当计数器超过阈值溢出了,就会触发JIT编译.
方法调用计数器统计的是方法被调用的次数,默认阈值在Client模式下是1500次,在Server模式下是10 000次,这个阈值可以通过虚拟机参数-XX:CompileThreshold来设定与更改.
如果不做任何设置,方法调用计数器统计的并不是方法被调用的绝对次数,而是一个相对的执行频率,即方法被调用的次数,当超过一定的时间限制,如果方法的调用次数仍然没有超过阈值,那这个方法的调用计数器就是被减少一半,这个过程称为方法调用计数器热度的衰减,而这段时间就称为此方法统计的半衰周期.
虚拟机参数:
关闭热度衰减:-XX:-UserCounterDecay
设置半衰周期的时间(单位是秒):-XX:CounterHalfLifeTime
回边:在字节码中遇到控制流向后跳转的指令称为"回边"
回边计数器的作用是统计一个方法中循环体代码执行的次数,显然,建立回边计数器的目的就是为了触发OSR编译.
虚拟机参数:
间接调整回边计数器的阈值:-XX:OnStackReplacePercentage
为什么是间接呢?因为回边计数器阈值是通过一个公式计算出来的
虚拟机运行在Client模式下,回边计数器阈值的计算公式:
虚拟机运行在Server模式下,回边计数器阈值的计算公式:
略
即时编译器优化技术一览:
类型 | 优化技术 |
编译器策略 | 延迟编译 分层编译 栈上替换 延迟优化 程序依赖图表示 |
基于性能监控的优化技术 | 乐观空值断言 乐观类型断言 乐观类型增强 乐观数组长度增强 裁剪未被选择的分支 乐观的多态内联 分支频率预测 调用频率预测 |
基于证据的优化技术 | 精确类型推断 内存值推断 内存值跟踪 常量拆叠 重组 操作符退化 空值检查消除 类型检测退化 类型检测消除 代数化简 公共子表达式消除 |
数据流敏感重写 | 条件常量传播 基于流承载的类型缩减转换 无用代码清除 |
语言相关的优化技术 | 类型继承关系分析 去虚拟机化 符号常量传播 自动装箱传播 逃逸分析 锁清除 锁膨胀 清除反射 |
内存及代码位置变换 | 表达式提升 表达式下沉 冗余存储消除 相邻存储合并 交汇点分离 |
循环变换 | 循环展开 循环剥离 安全点消除 迭代范围分离 范围检查消除 循环向量化 |
全局代码调整 | 内联 全局代码外提 基于热度的代码布局 Switch调整 |
控制流图变换 | 本地代码编排 本地代码封包 延迟槽填充 着色图寄存器分配 线性扫描寄存器分配 复写聚合 常量分裂 复写移除 地址模式匹配 指令窥孔优化 基于确定有限状态机的代码生成 |
这些代码优化变换是建立在代码的某种中间表示或机器码之上,绝不是建立在java源码之上的,只是为了展示方便,使用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;
}
接着进行冗余访问消除
把z=b.value替换为z=y
public void foo() {
y = b.value;
//do...stuff...
z = y;
sum = y+z;
}
进行复写传播
用y代替z
public void foo() {
y = b.value;
//do...stuff...
y = y;
sum = y+y;
}
最后进行无用代码消除
无用代码可能是永远不会被执行的代码,也可能是完全没有意义的代码,因此也称为"Dead Code"
public void foo() {
y = b.value;
//do...stuff...
sum = y+y;
}
可以看出进行优化后,省略了许多的代码语句,这是使用代码来表示,真实是体现在字节码和机器码指令上,所以差距会更加巨大,执行的效率也会更高.
接着我们来看看一些最具有代表性的优化技术
语言无关的经典优化技术之一:公共子表达式消除
语言相关的经典优化技术之一:数组范围检查消除
最重要的优化技术之一:方法内联
最前沿的优化技术之一:逃逸分析
公共子表达式消除:如果一个表达式E已经计算过了,并且从先前的计算到现在E中所有变量的值都没有发生变化,那么E的这次出行就成为了公共子表达式.对于这种表达式,没有必要花费时间再次对它进行计算,只要直接使用前面计算后的结果代替E可以了.如果这种优化仅限于程序的基本块内,便称为局部公共子表达式消除,如果这种优化的范围涵盖了多个基本块,那就称为全局公共子表达式消除.
如:int d = (c * b) * 12 + a + (a + b * c);
c*b与b*c是一样的表达式,且计算期间b与c的值是不变的,因此表达式可能被视为:
int d = E * 12 + a + (a + E);
此时,编译器还可能进行另一种优化:代数化简,化简后:
int d = E * 13 + a * 2;
数组边界检查消除:如果有一个数组foo[],在java语言中访问数组元素foo[i]的时候系统将会自动进行上下界的范围检查,带来安全性的同时,每次数组元素的读写都带有一次隐含的条件判定操作,对于拥有大量数组访问的程序代码,这无疑也是一种性能负担.
为了安全,数组边界检查肯定是必须做的,但是数组边界检查是不是必须在运行期间一次不漏地检查则是可以"商量"的.
比如数组下标是一个常量,更加常见的情况是数组访问发生在循环中,并且使用循环变量来进行数组访问.
这样就可以节省很多次的条件判断操作.
除了如数组边界检查优化这种尽可能把运行期检查提到编译期完成的思路之外,还有一种避免思路-----隐式异常处理.java中的空指针检查和算数运算中除数为零的检查都采用了这种思路.
例如以下伪代码:
if(foo != null) {
return foo.value;
}else {
throw new NullPointerException();
}
在使用了隐式异常优化之后,虚拟机会把上面伪代码转化为如下伪代码:
try {
return foo.value;
} catch (segment_fault) {
uncommon_trap();
}
虚拟机会注册一个Segment Fault信号的异常处理器,这样当foo不为空的时候,对value的访问是不会额外消耗一次对foo判空的开销.代价就是当foo真的为空时,必须转到异常处理器中恢复并抛出空指针异常,这个过程必须从用户态转到内核态中处理,结束后再回到用户态,速度远比一次判空检查慢.
当foo极少为空的时候,隐式异常优化是值得的,但假如foo经常为空的话,这样的优化反而会让程序更慢.
与语言相关的其他消除操作还有不少,如自动装箱消除,安全点消除,消除反射等.
方法内联上面已经讲过不过是把目标方法的代码"复制"到发起调用的方法之中,避免发生真实的方法调用而已,再给出一个例子:
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);
}
事实上test方法的内部全部都是无用代码,如果不做内联,即使进行了无用代码消除的优化,也无法发现任何"Dead Code",因为如果分开来看,两个方法里面的操作都可能是由意义的.
为了解决虚拟机的内联问题,java虚拟机设计团队引入了一种名为"类型继承关系分析"(CHA)的技术.
在很多情况下虚拟机进行的内联都是一种激进优化,这在高性能的商用虚拟机中很常见,出了内联之外,对于出现概率很小的隐式异常,使用概率很小的分支等都可以被激进优化"移除",如果真的出现了小概率事件,这是才会从"逃生门"回到解释状态重新执行.
逃逸分析:逃逸分析并不是直接优化代码的手段,而是为其他优化手段提供依据的分析技术.
逃逸分析的基本行为就是分析对象的动态作用域,当一个对象在方法中被定义后,它可能被外部方法所引用,例如作为调用参数传递到其他方法中,称为方法逃逸.甚至还有可能被外部线程访问到,譬如赋值给类变量或可以在其他线程中访问的实例变量,称为线程逃逸.
如果能证明一个对象不会逃逸到方法或线程之外,也就是别的方法或线程无法通过任何途径访问到这个对象,则可能为这个变量进行一些高效优化:
逃逸分析这项优化尚未足够成熟,不成熟的原因是不能保证逃逸分析的性能收益必定高于它的消耗.
分层编译
栈上替换
常量折叠
代数化简
公共子表达式消除
无用代码清除
类型继承关系分析
逃逸分析
冗余存储消除
范围检查消除
内联
复写移除
栈上分配
同步消除
标量替换
隐式异常处理
开启断言:-ea
关闭断言:-da
强制运行在Client模式(64位虚拟机不能运行在此模式下):-client
强制运行在Server模式:-server
查看版本及运行模式:-version
强制运行在解释模式:-Xint
强制运行在编译模式:-Xcomp
设置方法调用计数器阈值:-XX:CompileThreshold
关闭热度衰减:-XX:-UserCounterDecay
设置半衰周期的时间(单位是秒):-XX:CounterHalfLifeTime
间接调整回边计数器的阈值:-XX:OnStackReplacePercentage