记录点滴
我们的回忆

JVM的编译策略

本文主要讲述JVM的编译策略。

解释器

当虚拟机启动时,解释器可以首先发挥作用,而不必等待编译器全部编译完成再执行,这样可以省去许多不必要的编译时间。并且随着程序运行时间的推移,编译器逐渐发挥作用,根据热点探测功能,,将有价值的字节码编译为本地机器指令,以换取更高的程序执行效率。

hotspot中内嵌有2个JIT编译器,分别为Client Compiler,Server Compiler,但大多数情况下我们称之为C1编译器和C2编译器。

C1编译器

client compiler,又称C1编译器,较为轻量,只做少量性能开销比较高的优化,它占用内存较少,适合于桌面交互式应用。在寄存器分配策略上,JDK6以后采用的为线性扫描寄存器分配算法,其他方面的优化,主要有方法内联、去虚拟化、冗余消除等。

A、方法内联

多个方法调用,执行时要经历多次参数传递,返回值传递及跳转等,C1采用方法内联,把调用到的方法的指令直接植入当前方法中。-XX:+PringInlining来查看方法内联信息,-XX:MaxInlineSize=35控制编译后文件大小。

B、去虚拟化

是指在装载class文件后,进行类层次的分析,如果发现类中的方法只提供一个实现类,那么对于调用了此方法的代码,也可以进行方法内联,从而提升执行的性能。

C、冗余消除

在编译时根据运行时状况进行代码折叠或消除。

C2编译器

Server compiler,称为C2编译器,较为重量,采用了大量传统编译优化的技巧来进行优化,占用内存相对多一些,适合服务器端的应用。和C1的不同主要在于寄存器分配策略及优化范围,寄存器分配策略上C2采用的为传统的图着色寄存器分配算法,由于C2会收集程序运行信息,因此其优化范围更多在于全局优化,不仅仅是一个方块的优化。收集的信息主要有:分支的跳转/不跳转的频率、某条指令上出现过的类型、是否出现过空值、是否出现过异常等。

逃逸分析是C2进行很多优化的基础,它根据运行状态来判断方法中的变量是否会被外部读取,如不会则认为此变量是不会逃逸的,那么在编译时会做标量替换、栈上分配和同步消除等优化。

(1)标量替换

简单地说,就是用标量替换聚合量。这样做的好处是如果创建的对象并未用到其中的全部变量,则可以节省一定的内存。对于代码执行而言,无需去找对象的引用,也会更快一些。

(2)栈上分配

如果point没有逃逸,那么C2会选择在栈上直接创建Point对象的实例,而不是在JVM堆上。在栈上分配的好处一方面是加快速度,另一方面是回收时随着方法的结束,对象被回收了。

(3)同步消除

如果发现同步的对象未逃逸,那也就没有必要进行同步了,C2编译时会直接去掉同步。

C2还会基于拥有的运行信息来做其他优化,比如编译分支频率执行高的代码等。

运行后C1、C2编译出来的机器码如果不再符合优化条件,则会进行逆优化,也就是回到解释执行的方式,例如基于类层次分析编译的代码,当有新的相应的接口来实现类加入时,就执行逆优化。

OSR编译

除了C1、C2外,还有OSR(On Stack Replace)编译,只替换循环代码体的入口,C1、C2替换的是方法调用的入口。因此OSR编译后会出现的现象是方法的整段代码被编译了,但是只有循环体部分才执行编译后的机器码,其他部分仍是解释执行。

当机器配置CPU超过2核且内存超过2G,默认为server模式,32位的windows始终选择的是client模式。

分层编译

Java7默认开启分层编译(tiered compilation)策略,由C1编译器和C2编译器相互协作共同来执行编译任务。C1编译器会对字节码进行简单和可靠的优化,以达到更快的编译速度;C2编译器会启动一些编译耗时更长的优化,以获取更好的编译质量。

(1)解释器不再收集运行状态信息,只用于启动并触发C1编译
(2)C1编译后生成带收集运行信息的代码
(3)C2编译,基于C1编译后代码收集的运行信息进行激进优化,当激进优化的假设不成立时,再退回使用C1编译的代码

程序在未编译期间解释执行有个阈值,SunJDK主要依据方法上的两个计数器是否超过阈值来判断:

  • A、调用计数器,即方法被调用的次数,CompileThreshold,该值是指当方法被调用多少次后,就编译为机器码,client模式默认为1500次,server模式默认为1万次,可以在启动时添加-XX:CompileThreshold=10000来设置该值。
  • B、回边计数器,即方法中循环执行部分代码的执行次数,OnStackReplacePercentage,该值用于/参与计算是否触发OSR编译的阈值,client默认为933,sever默认为140,可以通过-XX: OnStackReplacePercentage=140来设置。

client模式下的计算规则为CompileThreshold*OnStackReplacePercentage/100,server模式下计算规则为CompileThreshold*(OnStackReplacePercentage-InterpreterProfilePercentage)/100。InterpreterProfilePercentage,默认为33。

当方法上的回边计数器到达这个值时,触发后台的OSR编译,并将方法上累积的调用计数器设置为CompileThreshold 的值,同时将回边计数器设置为CompileThreshold/2的值。这样做一方面是为了避免OSR编译频繁被触发,另一方面是以便当方法被再次调用时即触发正常的编译,当累积的回边计数器的值再次达到该值时先检查OSR编译是否完成,如果已完成,则在执行循环体的代码时进入编译后的代码,如果未完成,继续把当前回边计数器的累计值再减掉一些,默认情况下,对于回边的情况,server模式下只要回边次数达到10700次(10000*(140-33)),就会触发OSR编译。

解释器与编译器并存

如果选用完全解释策略,那么编译器将停止所有的工作,字节码将完全依靠解释器逐行解释执行。如果选用完全编译策略,那么解释器仍然会在编译器无法进行的特殊情况下介入运行,这主要是确保程序能够最终顺序执行。

SunJDK之所以未选择在启动时即编译成机器码的原因如下:
(1)静态编译并不能根据程序的运行状态来优化执行的代码,C2这种方式是根据运行状态来进行动态编译的,例如分支判断、逃逸分析等,这些措施会对提升程序执行的性能起到很大的帮助,在静态编译的情况下是无法实现的,给C2收集运行数据越长的时间,编译出来的代码会越优。
(2)解释执行比编译执行更节省内存
(3)启动时解释执行的启动速度比编译再启动更快。

参考

未经允许不得转载:我们的回忆 » JVM的编译策略

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

我们的回忆 记录点滴

标签云会员中心