运行期优化——深入理解Java虚拟机

解析与即时编译共存：

在部分的商用虚拟机(Sun HotSpot,IBM J9)中，Java程序最初时通过解析器进行解析执行的，当虚拟机发现某个方法或者代码块的运行特别频繁时，就会把这些代码认定为“热点代码”(Hot Spot Code)。为提高热点代码的执行效率，在运行时，虚拟机将会把这些代码编译成本地平台相关的机器码，并进行各层次的优化，完成这个任务的编译器称为即时编译器（Just In Time Complier，下文称为JIT编译器）。

 

即时编译技术的重要地位：

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

 

 

一.解析器与编译器

 

为什么当前主流的虚拟机都采用解析器与编译器并存的架构？

尽管并不是所有的Java虚拟机都采用解析器与编译器并存的架构，但许多主流的商用虚拟机，例如HotSpot，J9等，都同时包含解析器与编译器。解析器与编译器两者各有优势：当程序需要迅速启动和执行的时候，解析器可以首先发挥作用，省去编译的时间，立即执行。在程序执行之后，随着时间的推移，编译器逐渐发挥作用，，把越来越多的代码编译成本地代码之后，可以获去更高的执行效率。当程序运行环境中内存资源限制较大,则可以使用解析执行节约内存，反之使用编译执行来调高执行效率。

 

C1与C2是谁？

HotSpot虚拟机中内置了两个即时编译器，分别称为Client Compiler(C1) 和 Server Compiler(C2)，目前主流的HotSpot中，默认采用解析器与其中一个编译器直接配合的方式工作。

 

分层编译，速度效率的最佳平衡：

由于即时编译器编译本地代码需要占用程序运行时间，要编译出优化程度更高的代码，所需花费的时间可能更长：而且想要编译出优化程度更高的代码，解析器可能还要替编译器收集性能监控信息，这对解析执行的速度也有影响，为了在程序启动速度与运行效率之间达到最佳的平衡，HotSpot虚拟机启用了分层编译的策略。分层编译根据编译器编译，优化的规模与耗时，划分出不同的编译层次，其中包括：

 

1.第零层：程序解析执行，解析器不开启性能监控功能，可触发1层编译。

2.第一层：也称C1编译，将字节码编译为本地码，进行简单，可靠的优化，如有必要可以加入性能监控的逻辑。

3.第二层：也称为C2编译，也是将字节码编译为本地代码，但是会器用一些编译耗时较长的优化，甚至会根据性能监控信息进行一些不可靠的激进优化（需要承担风险）。

 

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

 

 

 

二.编译对象与触发条件

 

上文提到过，在运行过程中会被即时编译器编译的“热点代码”有两类，即：

1.被多次调用的方法。

2.被多次执行的方法体。

 

 

如何理解：

前者很好理解，一个方法被调用的次数多，自然方法体内代码执行次数自然就多，它成为“热点代码”也就理所当然了。二后者则是为了解决一个方法只被调用过一次或少量几次，但是方法体能不存在循环，这样循环内的代码也被重复执行多次，因此这些代码也应该被认为是“热点代码”。

 

两种触发，一种结果：

对于第一种情况，由于是由方法调用触发器的编译，因为编译器理所当然地会以整个方法作为编译对象，这种编译也是虚拟机中标准的JIT编译方式。

对于第二种情况，尽管编译动作是循环体触发的，但编译器依然会以整个方法做为编译对象。这种因为编译放生在方法执行的过程中，因此形象的称之为栈上替换（On Stack Replacement）,简称为OSR编译，即方法栈帧还在栈上，方法就被替换了。

 

如何判断某段代码是否为热点代码？

 

判断一段代码是不是热点代码，是不是需要触发即时编译器，这样的行为称为热点探测(Hot Spot Detection),其实进行热点探测不一定要知道具体方法被调用了多少次，目前最主要的热点他测判定方法一两种，分别如下。

1.基于采样的热点探测：采用这种方法的虚拟机会周期性的检查个各个线程的栈顶， 如果发现某个方法经常出现在栈顶上，那这个方法就是“热点方法”。基于采样点的热 点探测的好处是实现简单，高效，还可以很容易地获取方法调用关系(将调用堆栈展开 即可)，缺点是很难精确地确认一个方法的热度，容易因为线程阻塞或别的外界因素影 响而扰乱热点探测。

2.基于计数器的热点探测：采用这种方法的虚拟机会为每个方法(甚至代码块)建立计数 器，统计方法的执行次数，如果执行次数超过一定的阀值，就认为是“热点方法”。这 种统计方法实现起来麻烦一些，需要为每个方法建立并维护计数器，而且不能直接获取 到方法的调用关系，但是它的统计结果相对来说精确严谨。

 

应用在我们的HotSpot：

在Hot Spot虚拟机中使用第二种——基于计数器的热点探测方法，因此它为每个方法准备了两类计数器:方法调用计数器和回边计数器。在确定虚拟机运行的前提下，这两个计数器都有一个确定的阀值，当计数器超过阀值溢出了，就会触发JIT编译。

 

 

方法调用计数器是什么？

 

首先看看方法调用计数器：顾名思义，这个计数器就用于统计方法被调用的次数，他的默认阀值在Client模式下是1500次，咋Server下是10000次，这个阀值可以通过虚拟机参数设定。当一个方法被调用时，会先检查该方法是否存在被JIT编译过的版本，如果存在，则优先使用编译后的本地代码来执行。否则，将该方法的调用计数器加1，然后判断调用计数器与回边计数器的值之和是否超过阀值。如果已经超过阀值，那么将会向即时编译器提交一个该方法的代码编译请求。

 

如果不做任何设置，方法调用计数器并不是方法被调用的绝对次数，而是一个相对的执行频率，即一段时间之内方法被调用的次数。当超过一定的时间限度，如果方法的调用次数仍然不足以让它提交给即时编译器，那这个方法调用计数器值就会减少一半，这个过程称为方法调用计数器热度的衰减，而这段时间称为此方法统计的半衰期。

 

回边计数器是什么？

 

回边计数器：它的作用是统计一个方法中循环体代码的执行次数，在字节码中遇到控制流向后跳转的指令称为“回边”。显然，建立回边计数器的目的是为了触发OSR编译。

 

当解释器遇到一条回边指令时，会现查找将要执行的代码片段是否已经有编译好的版本，如果有，它将会优先执行已经编译好的代码，否则就把回边计数器的值加1，然后判断方法调用计数器与回边计数器的值之和是否超过会变计数器的阀值，如果超过了，就提交一个OSR编译请求，并且把回边计数器的值降低一些。

 

与方法调用计数器不同的是，回边计数器没有热度衰减，因此这个计数器统计的就是该方法循环执行的绝对次数。当计数器溢出时，它还会把方法计数器的值也调整到溢出的状态，这样下次进入该方法的时候就会执行标准编译过程JIT。

 

 

 

 

三.编译过程

 

在默认情况下，无论是方法调用产生的即时编译请求JIT还是OSR编译请求，虚拟机在代码编译器还未完成之前，都仍任按照解析方式继续执行，而编译动作则在后台的编译线程中进行。

 

 

在后台执行编译的过程中，编译器做了些什么事情呢？Server Compiler 和 Client Compiler两个编译器的编译过程是不一样的。

 

 

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

1.第一阶段：一个平台独立的前端将字节码啊构造称一种高级的中间代码表示(High Level Intermediate Representation ,HIR)。在此之前编译器会在字节码上完成一部分基础 优化，如方法内联，常量优化等优化将会在字节码被构造称HIR之前完成。

2.第二阶段：一个平台相关的后端从HIR中产生低级中间代码表示，而再此之前会在 HIR上完成另外一些优化，如空值检查，消除，范围检查消除等，以便让HIR达到更 高效的代码表示。

3.第三阶段：最后阶段是平台相关性的后端使用闲心扫描算法，在LIR上分配寄存器， 并在LIR上做窥孔优化，然后生成机器代码。

 

而对于Server Compiler 则是专门面向服务端的典型应用并未服务端性能配置特别调整过的编译器，也是一个充分优化过的高级编译器，他会执行所有经典的优化动作，如无用代码消除，循环展开，循环表达式外提，消除公共子表达式，常量传播等。