Java程序最初是通过解释器（Interpreter）进行解释执行的，当虚拟机发现某个方法或代码块的运行特别频繁时，就会把这些代码认定为“热点代码”，为了提高热点代码的执行效率，在运行时，
虚拟机将会把这些代码编译成与本地平台相关的机器码，并进行各种层次的优化，完成这个任务的编译器称为即时编译器，即时编译器编译性能的好坏、
代码优化程度的高低却是衡量一款商用虚拟机优秀与否的最关键的指标之一，本篇博客，我们将学习即时编译器的运作过程。（本篇博客提及的编译器、
即时编译器都是指HotSpot虚拟机内的即时编译器，虚拟机也是特指HotSpot
虚拟机。）
HotSpot虚拟机内的即时编译器
解释器与编译器
许多主流的商用虚拟机，如HotSpot、 J9等，都同时包含解释器与编译器，解释器与编译器两者各有优势：当程序需要迅速启动和执行的时候，解释器可以首先发挥作用，省去编译的时间，立即执行。在程序运行后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码之后，可以获取更高的执行效率。
当程序运行环境中内存资源限制较大（如部分嵌入式系统中），可以使用解释执行节约内存，反之可以使用编译执行来提升效率。
解释器还可以作为编译器激进优化时的一个“逃生门”，让编译器根据概率选择一些大多数时候都能提升运行速度的优化手段，当激进优化的假设不成立，如加载了新类后类型继承结构出现变化、
出现“罕见陷阱”（Uncommon Trap）时可以通过逆优化（Deoptimization）退回到解释状态继续执行（部分没有解释器的虚拟机中也会采用不进行激进优化的C1编译器[2]担任“逃生门”的
角色）
HotSpot虚拟机中内置了两个即时编译器，分别称为Client Compiler和Server
Compiler，或者简称为C1编译器和C2编译器（也叫Opto编译器）。 目前主流的HotSpot虚拟机（Sun系列JDK
1.7及之前版本的虚拟机）中，默认采用解释器与其中一个编译器直接配合的方式工作，程序使用哪个编译器，取决于虚拟机运行的模式，HotSpot虚拟机会根据自身版本与宿主机器的硬件性能自动选择运行模式，用户也可以使用“-client”或“-server”参数去强制指定虚拟机运行在Client模式或Server模式。
无论采用的编译器是Client Compiler还是Server Compiler，解释器与编译器搭配使用的方式在虚拟机中称为“混合模式”（Mixed
Mode），用户可以使用参数“-Xint”强制虚拟机运行于“解释模式”（Interpreted Mode），这时编译器完全不介入工作，全部代码都使用解释方式执行。
另外，也可以使用参数“-Xcomp”强制虚拟机运行于“编译模式”（Compiled Mode），这时将优先采用编译方式执行程序，但是解释器仍然要在编译无法进行的情况下介入执行过程，可以通过虚拟机的“-version”命令的输出结果显示出这3种模式
C：\＞java-version
java version"1.6.0_22"
Java（TM）SE Runtime Environment （build 1.6.0_22-b04）
Dynamic Code Evolution 64-Bit Server VM （build
0.2-b02-internal， 19.0-b04-internal,mixed mode）
C：\＞java-Xint-version
java version"1.6.0_22"
Java（TM）SE Runtime Environment （build 1.6.0_22-b04）
Dynamic Code Evolution 64-Bit Server VM（build
0.2-b02-internal，19.0-b04-internal,interpreted
mode）
C：\＞java-Xcomp-version
java version"1.6.0_22"
Java（TM）SE Runtime Environment（build 1.6.0_22-b04）
Dynamic Code Evolution 64-Bit Server VM （build
0.2-b02-internal，19.0-b04-internal,compiled mode） |
由于即时编译器编译本地代码需要占用程序运行时间，为了在程序启动响应速度与运行效率之间达到最佳平衡，HotSpot虚拟机还会逐渐启用分层编译（Tiered
Compilation）的策略，在JDK 1.7的Server模式虚拟机中作为默认编译策略被开启。
分层编译根据编译器编译、 优化的规模与耗时，划分出不同的编译层次，其中包括：
第0层，程序解释执行，解释器不开启性能监控功能（Profiling），可触发第1层编译。
第1层，也称为C1编译，将字节码编译为本地代码，进行简单、 可靠的优化，如有必要将加入性能监控的逻辑。
第2层（或2层以上），也称为C2编译，也是将字节码编译为本地代码，但是会启用一些编译耗时较长的优化，甚至会根据性能监控信息进行一些不可靠的激进优化。
实施分层编译后，Client Compiler和Server Compiler将会同时工作，许多代码都可能会被多次编译，用Client
Compiler获取更高的编译速度，用Server Compiler来获取更好的编译质量，在解释执行的时候也无须再承担收集性能监控信息的任务。
编译对象与触发条件
在运行过程中会被即时编译器编译的“热点代码”有两类
1.被多次调用的方法
2.被多次执行的循环体
前者很好理解，一个方法被调用得多了，方法体内代码执行的次数自然就多，它成为“热点代码”是理所当然的。
而后者则是为了解决一个方法只被调用过一次或少量的几次，但是方法体内部存在循环次数较多的循环体的问题，这样循环体的代码也被重复执行多次，因此这些代码也应该认为是“热点代码”。
对于第一种情况，由于是由方法调用触发的编译，因此编译器理所当然地会以整个方法作为编译对象，这种编译也是虚拟机中标准的JIT编译方式。
而对于后一种情况，尽管编译动作是由循环体所触发的，但编译器依然会以整个方法（而不是单独的循环体）作为编译对象。
这种编译方式因为编译发生在方法执行过程之中，因此形象地称之为栈上替换（OnStack Replacement，简称为OSR编译，即方法栈帧还在栈上，方法就被替换了）。
判断一段代码是不是热点代码，目前主要的热点探测判定方式有两种
基于采样的热点探测（Sample Based Hot Spot Detection）：采用这种方法的虚拟机会周期性地检查各个线程的栈顶，如果发现某个（或某些）方法经常出现在栈顶，那这个方法就是“热点方法”。
基于采样的热点探测的好处是实现简单、 高效，还可以很容易地获取方法调用关系（将调用堆栈展开即可），缺点是很难精确地确认一个方法的热度，容易因为受到线程阻塞或别的外界因素的影响而扰乱热点探测。
基于计数器的热点探测（Counter Based Hot Spot Detection）：采用这种方法的虚拟机会为每个方法（甚至是代码块）建立计数器，统计方法的执行次数，如果执行次数超过一定的阈值就认为它是“热点方法”。
这种统计方法实现起来麻烦一些，需要为每个方法建立并维护计数器，而且不能直接获取到方法的调用关系，但是它的统计结果相对来说更加精确和严谨。
在HotSpot虚拟机中使用的是第二种——基于计数器的热点探测方法，因此它为每个方法准备了两类计数器：方法调用计数器（Invocation
Counter）和回边计数器（Back Edge
Counter）。
在确定虚拟机运行参数的前提下，这两个计数器都有一个确定的阈值，当计数器超过阈值溢出了，就会触发JIT编译。
我们首先来看看方法调用计数器。 这个计数器就用于统计方法被调用的次数，它的默认阈值在Client模式下是1500次，在Server模式下是10
000次，这个阈值可以通过虚拟机参数-XX：CompileThreshold来人为设定。 当一个方法被调用时，会先检查该方法是否存在被JIT编译过的版本，如果存在，则优先使用编译后的本地代码来执行。
如果不存在已被编译过的版本，则将此方法的调用计数器值加1，然后判断方法调用计数器与回边计数器值之和是否超过方法调用计数器的阈值。
如果已超过阈值，那么将会向即时编译器提交一个该方法的代码编译请求。
如果不做任何设置，执行引擎并不会同步等待编译请求完成，而是继续进入解释器按照解释方式执行字节码，直到提交的请求被编译器编译完成。
当编译工作完成之后，这个方法的调用入口地址就会被系统自动改写成新的，下一次调用该方法时就会使用已编译的版本。
如果不做任何设置，方法调用计数器统计的并不是方法被调用的绝对次数，而是一个相对的执行频率，即一段时间之内方法被调用的次数。
当超过一定的时间限度，如果方法的调用次数仍然不足以让它提交给即时编译器编译，那这个方法的调用计数器就会被减少一半，这个过程称为方法调用计数器热度的衰减（Counter
Decay），而这段时间就称为此方法统计的半衰周期（Counter Half Life Time）。
进行热度衰减的动作是在虚拟机进行垃圾收集时顺便进行的，可以使用虚拟机参数-XX：-UseCounterDecay来关闭热度衰减，让方法计数器统计方法调用的绝对次数，这样，只要系统运行时间足够长，绝大部分方法都会被编译成本地代码。
另外，可以使用-XX：CounterHalfLifeTime参数设置半衰周期的时间，单位是秒。
回边计数器，它的作用是统计一个方法中循环体代码执行的次数，在字节码中遇到控制流向后跳转的指令称为“回边”（Back
Edge）。 显然，建立回边计数器统计的目的就是为了触发OSR编译。
关于回边计数器的阈值，虽然HotSpot虚拟机也提供了一个类似于方法调用计数器阈值-XX：CompileThreshold的参数-XX：BackEdgeThreshold供用户设置，但是当前的虚拟机实际
上并未使用此参数，因此我们需要设置另外一个参数-XX：OnStackReplacePercentage来间接调整回边计数器的阈值，其计算公式如下。
方法调用计数器阈值（CompileThreshold）×OSR比率（OnStackReplacePercentage）/100
其中OnStackReplacePercentage默认值为933，如果都取默认值，那Client模式虚拟机的回边计数器的阈值为13995。
虚拟机运行在Server模式下，回边计数器阈值的计算公式为：
方法调用计数器阈值（CompileThreshold）×（OSR比率（OnStackReplacePercentage）-解释器监控比率（InterpreterProfilePercentage）/100
其中OnStackReplacePercentage默认值为140，InterpreterProfilePercentage默认值为33，如果都取默认值，那Server模式虚拟机回边计数器的阈值为10700。
当解释器遇到一条回边指令时，会先查找将要执行的代码片段是否有已经编译好的版本，如果有，它将会优先执行已编译的代码，否则就把回边计数器的值加1，然后判断方法调用计数器与回边计数器值之和是否超过回边计数器的阈值。
当超过阈值的时候，将会提交
一个OSR编译请求，并且把回边计数器的值降低一些，以便继续在解释器中执行循环，等待编译器输出编译结果
与方法计数器不同，回边计数器没有计数热度衰减的过程，因此这个计数器统计的就是该方法循环执行的绝对次数。
当计数器溢出的时候，它还会把方法计数器的值也调整到溢出状态，这样下次再进入该方法的时候就会执行标准编译过程。
上述两张图都仅仅描述了Client VM的即时编译方式，对于Server VM来说，执行情况会比上面的描述更复杂一些。
注：
1.除这两种方式外，还有其他热点代码的探测方式，如基于“踪迹”（Trace）的热点探测在最近相当流行，像FireFox中的TraceMonkey和Dalvik中新的JIT编译器都用了这种热点探测方
式。
2.回边的次数并不是循环次数，因为并非所有的循环都是回边，如空循环实际上就可以视为自己跳转到自己的过程，因此并不算作控制流向后跳转，也不会被回边计数器统计。
编译过程
在默认设置下，无论是方法调用产生的即时编译请求，还是OSR编译请求，虚拟机在代码编译器还未完成之前，都仍然将按照解释方式继续执行，而编译动作则在后台的编译线程中进行。
用户可以通过参数-XX：-BackgroundCompilation来禁止后台编译，在禁止后台编译后，一旦达到JIT的编译条件，执行线程向虚拟机提交编译请求后将会一直等待，直到编译过程完成后再开始执行编译器输出的本地代码。
那么在后台执行编译的过程中，编译器做了什么事情呢？Server Compiler和Client Compiler两个编译器的编译过程是不一样的。
对于Client Compiler来说，它是一个简单快速的三段式编译器，主要的关注点在于局部性的优化，而放弃了许多耗时较长的全局优化手段。
在第一个阶段，一个平台独立的前端将字节码构造成一种高级中间代码表示（HighLevel Intermediate
Representaion,HIR）。 HIR使用静态单分配（Static Single Assignment,SSA）
的形式来代表代码值，这可以使得一些在HIR的构造过程之中和之后进行的优化动作更容易实现。 在此之前编译器会在字节码上完成一部分基础优化，如方法内联、
常量传播等优化将会在字节码被构造成HIR之前完成。
在第二个阶段，一个平台相关的后端从HIR中产生低级中间代码表示（Low-Level Intermediate
Representation,LIR），而在此之前会在HIR上完成另外一些优化，如空值检查消除、 范围检查消除等，以便让HIR达到更高效的代码表示形式。
最后阶段是在平台相关的后端使用线性扫描算法（Linear Scan Register Allocation）在LIR上分配寄存器，并在LIR上做窥孔（Peephole）优化，然后产生机器代码。
Client Compiler的
大致执行过程如图所示。
而Server Compiler则是专门面向服务端的典型应用并为服务端的性能配置特别调整过的编译器，也是一个充分优化过的高级编译器，几乎能达到GNU
C++编译器使用-O2参数时的优化强度，它会执行所有经典的优化动作，如无用代码消除等，另外，还可能根据解释器或Client
Compiler提供的性能监控信息，进行一些不稳定的激进优化，如守护内联（Guarded Inlining）、
分支频率预测（Branch Frequency Prediction）等。
以即时编译的标准来看，Server Compiler无疑是比较缓慢的，但它的编译速度依然远远超过传统的静态优化编译器，而且它相对于Client
Compiler编译输出的代码质量有所提高，可以减少本地代码的执行时间，从而抵消了额外的编译时间开销，所以也有很多非服务端的应用选择使用Server模式的虚拟机运行。
查看及分析即时编译结果
这里的运行参数有一部分需要Debug或FastDebug版虚拟机的支持，Product版的虚拟机无法使用这部分参数。
可以在OpenJDK网
站上直接下载FastDebug版的JDK（从JDK 6u25之后Oracle官网就不再提供FastDebug的JDK下载了）。
测试代码
public static
final int NUM=15000；
public static int doubleValue（int i）{
//这个空循环用于后面演示JIT代码优化过程
for（int j=0；j＜100000；j++）；
return i*2；
}p
ublic static long calcSum（）{
long sum=0；
for（int i=1；i＜=100；i++）{
sum+=doubleValue（i）；
}r
eturn sum；
}p
ublic static void main（String[]args）{
for（int i=0；i＜NUM；i++）{
calcSum（）；
}} |
首先运行这段代码，并且确认这段代码是否触发了即时编译，要知道某个方法是否被编译过，可以使用参数-XX：+PrintCompilation要求虚拟机在即时编译时将被编译成本地代码的方法名称打印出来，（其中带有“%”的输出说明是由回边计数器触发的OSR编译）。
VM option'+PrintCompilation'
310 1 java.lang.String：charAt（33 bytes）
329 2 org.fenixsoft.jit.Test：calcSum（26 bytes）
329 3 org.fenixsoft.jit.Test：doubleValue（4 bytes）
332 1%org.fenixsoft.jit.Test：main@5（20 bytes） |
从输出的确认信息中可以确认main（）、 calcSum（）和doubleValue（）方法已经被编译，我们还可以加上参数-XX：+PrintInlining要求虚拟机输出方法内联信息
内联信息
VM option'+PrintCompilation'
VM option'+PrintInlining'
273 1 java.lang.String：charAt（33 bytes）
291 2 org.fenixsoft.jit.Test：calcSum（26 bytes）
@9 org.fenixsoft.jit.Test：doubleValue inline（hot）
294 3 org.fenixsoft.jit.Test：doubleValue（4 bytes）
295 1%org.fenixsoft.jit.Test：main@5（20 bytes）
@5 org.fenixsoft.jit.Test：calcSum inline（hot）
@9 org.fenixsoft.jit.Test：doubleValue inline（hot） |
从代码输出中可以看到方法doubleValue（）被内联编译到calcSum（）中，而calcSum（）又被内联编译到方法main（）中，所以虚拟机再次执行main（）方法的时候（举例而已，main（）方法并不会运行两次），calcSum（）和doubleValue（）方法都不会再被调用，它们的代码逻辑都被直接内联到main（）方法中了。
除了查看哪些方法被编译之外，还可以进一步查看即时编译器生成的机器码内容，不过如果虚拟机输出一串0和1，对于我们的阅读来说是没有意义的，机器码必须反汇编成基本的汇编语言才可能被阅读。
虚拟机提供了一组通用的反汇编接口[1]，可以接入各种平台下的反汇编适配器来使用，如使用32位80x86平台则选用hsdis-i386适配器，其余平台的适配器还有hsdis-amd64、
hsdis-sparc和hsdis-sparcv9等，可以下载或自己编译出反汇编适配器[2]，然后将
其放置在JRE/bin/client或/server目录下，只要与jvm.dll的路径相同即可被虚拟机调用。
在为虚拟机安装了反汇编适配器之后，就可以使用-XX：+PrintAssembly参数要求虚拟机打印编译方法的汇编代码了
如果没有HSDIS插件支持，也可以使用-XX+PrintOptoAssembly（用于Server
VM）或-
XX：+PrintLIR（用于Client VM）来输出比较接近最终结果的中间代码表示， 从阅读角度来说，使用-XX：+PrintOptoAssembly参数输出的伪汇编结果包含了更多的信息（主要是注释），利于阅读并理解虚拟机JIT编译器的优化结果。
本地机器码反汇编信息
000 B1：#N1＜-BLOCK
HEAD IS JUNK Freq：1
000 pushq rbp
subq rsp，#16#Create frame
nop#nop for patch_verified_entry
006 movl RAX,RDX#spill
008 sall RAX，#1
00a addq rsp，16#Destroy frame
popq rbp
testl rax，[rip+#offset_to_poll_page]#Safepoint：poll
for GC
…… |
前面提到的使用-XX：+PrintAssembly参数输出反汇编信息需要Debug或者FastDebug版的虚拟机才能直接支持，如果使用Product版的虚拟机，则需要加入参数-XX：
+UnlockDiagnosticVMOptions打开虚拟机诊断模式后才能使用。
如果除了本地代码的生成结果外，还想再进一步跟踪本地代码生成的具体过程，那还可以使用参数-XX：+PrintCFGToFile（使用Client
Compiler）或-XX：PrintIdealGraphFile（使用Server Compiler）令虚拟机将编译过程中各个阶段的数据（例如，对C1编译器来说，包括字节码、
HIR生成、 LIR生成、 寄存器分配过程、 本地代码生成等数据）输出到文件中。 然后使用Java
HotSpot Client Compiler Visualizer （用于分析Client Compiler）或Ideal
Graph Visualizer（用于分析Server Compiler）打开这些数据文件进行分析。
Ideal Graph Visualizer加载ideal.xml文件后，在Outline面板上将显示程序运行过程中编译过的方法列表,其中doubleValue（）方法出现了两次，这是由于该方法的编译结果存在标准编译和OSR编译两个版本。
展开方法根节点，可以看到下面罗列了方法优化过程的各个阶段（根据优化措施的不同，每个方法所经过的阶段也会有所差别）的Ideal图，我们先打开“After
Parsing”这个阶段。
JIT编译器在编译一个Java方法时，首先要把字节码解析成某种中间表示形式，然后才可以继续做分析和优化，最终生成代码。
“After Parsing”就是Server Compiler刚完成解析，还没有做任何优化时的Ideal图表示。
在打开这个图后，读者会看到其中有很多有颜色的
方块，如下图所示。 每一个方块就代表了一个程序的基本块（Basic Block），基本块的特点是只有唯一的一个入口和唯一的一个出口，只要基本块中第一条指令执行了，那么基本块内所有执行都会按照顺序仅执行一次。
doubleValue（）方法虽然只有简单的两行字，但是按基本块划分后，形成的图形结构要比想象中复杂得多，这一方面是要满足Java语言所定义的安全需要（如类型安全、
空指针检查）和Java虚拟机的运作需要（如Safepoint轮询），另一方面是由于有些程序代码中一行语句就可能形成好几个基本块（例如循环）。
对于例子中的doubleValue（）方法，如果忽略语言安全检查的基本块，可以简单理解为按顺序执行了以下几件事情：
1）程序入口，建立栈帧。
2）设置j=0，进行Safepoint轮询，跳转到4）的条件检查。
3）执行j++。
4）条件检查，如果j＜100000，跳转到3）。
5）设置i=i*2，进行Safepoint轮询，函数返回。
以上几个步骤，反映到Ideal Graph Visualizer的图上，就是如下图所示的内容。
这样我们要看空循环是否优化，或者何时优化，只要观察代表循环的基本块是否消除，或者何时消除就可以了。
要观察到这一点，可以在Outline面板上右键点击“Difference to current graph”，让软件自动分析指定阶段与当前打开的Ideal图之间的差异，如果基本块被消除了，将会以红色显示。
对“After Parsing”和“PhaseIdealLoop 1”阶段的Ideal图进行差异分析，发现在“PhaseIdealLoop1”阶段循环操作被消除了，如下图所示，这也就说明空循环实际上是不会被执行的。
从“After Parsing”阶段开始，一直到最后的“Final Code”阶段，可以看到doubleValue（）方法的Ideal图从繁到简的变迁过程，这也是Java虚拟机在尽力优化代码的过程。
到了最后的“Final Code”阶段，不仅空循环的开销消除了，许多语言安全Safepoint轮询的操作也一起消除了，因为编译器判断即使不做这些安全保障，虚拟机也不会受到威胁。
最后提醒一下读者，要输出CFG或IdealGraph文件，需要一个Debug版或FastDebug版的虚拟机支持，Product版的虚拟机无法输出这些文件。
|
