晚期（运行期）优化

Posted 2022-12-13 法海你懂不

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

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

HotSpot虚拟机内的即时编译器

尽管并不是所有的 Java 虚拟机都采用解释器与编译器并存的架构，但许多主流的商用虚拟机，如 HotSpot、J9 等，都同时包含解释器与编译器。

解释器与编译器两者各有优势：

• 当程序需要迅速启动和执行的时候，解释器可以首先发挥作用，省去编译的时间，立即执行。
  在程序运行后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码之后，可以获取更高的执行效率。
• 当程序运行环境中内存资源限制较大（如部分嵌入式系统中），可以使用解释执行节约内存，反之可以使用编译执行来提升效率。
• 解释器还可以作为编译器激进优化时的一个 “逃生门”，让编译器根据概率选择一些大多数时候都能提升运行速度的优化手段，当激进优化的假设不成立，如加载了新类后类型继承结构出现变化、出现 “罕见陷阱”（Uncommon Trap）时可以通过逆优化（Deoptimization）退回到解释状态继续执行。

解释器与编译器

HotSpot虚拟机中内置了两个即时编译器，分别称为Client Compiler和Server Compiler，或简称为C1编译器和C2编译器。
目前HotSpot 虚拟机中，默认采用解释器与其中一个编译器直接配合的方式工作，程序使用哪个编译器，取决于虚拟机运行的模式。

• HotSpot 虚拟机会根据自身版本与宿主机器的硬件性能自动选择运行模式；
  用户也可以使用 -client 或 -server 参数去强制指定虚拟机运行在 Client 模式或 Server 模式。

• 无论采用的编译器是 Client Compiler 还是 Server Compiler，解释器与编译器默认会以 “混合模式” （Mixed Mode）的方式在虚拟机中执行代码。
  可以使用参数 “-Xint” 强制虚拟机运行于 “解释模式”（Interpreted Mode），这时编译器完全不介入工作，全部代码都使用解释方式执行。
  可以使用参数 “-Xcomp” 强制虚拟机运行于 “编译模式”（Compiled Mode），这时将优先采用编译方式执行程序，但是解释器仍然要在编译无法进行的情况下介入执行过程，

由于即时编译器编译本地代码需要占用程序运行时间，要编译出优化程度更高的代码，所花费的时间可能更长；而且想要编译出优化程度更高的代码，解释器可能还要替编译器收集性能监控信息，这对解释执行的速度也有影响。
为了在程序启动响应速度与运行效率之间达到最佳平衡，HotSpot 虚拟机还会逐渐启用分层编译（Tiered Compilation）的策略，分层编译的概念在 JDK 1.6 时期出现，后来一直处于改进阶段，最终在 JDK 的 Server 模式虚拟机中作为默认编译策略被开启。分层编译根据编译器编译、优化的规模与耗时，划分出不同的编译层次，其中包括：

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

编译对象与触发条件

对热点代码的处理方式

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

• 被多次调用的方法。
• 被多次执行的循环体

对于第一种情况，由于是由方法调用触发的编译，因此编译器理所当然地会以整个方法作为编译对象，这种编译也是虚拟机中标准的 JIT 编译方式。
对于后一种情况，尽管编译动作是由循环体所触发的，但编译器依然会以整个方法（而不是单独的循环体）作为编译对象。这种编译方式因为编译发生在方法执行过程之中，因此形象地称之为栈上替换（On Stack Replacement，简称为 OSR 编译，即方法栈帧还在栈上，方法就被替换了）。

判断是否为热点代码

判断一段代码是不是热点代码，是不是需要触发即时编译，这样的行为称为热点探测（Hot Spot Detection），其实进行热点探测并不一定要知道方法具体被调用了多少次，目前主要的热点探测判定方式有两种（注：还有其他热点代码的探测方式，如基于“踪迹”（Trace）的热点探测再最近相当流行，像 Firefox 中的 TraceMonkey 和 Dalvik 中新的 JIT 编译器都用了这种热点探测方式），分别如下：

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

在 HotSpot 虚拟机中使用的是”基于计数器的热点探测方法”，因此它为每个方法准备了两类计数器：方法调用计数器（Invocation Counter）和回边计数器（Back Edge Counter）。

• 方法调用计数器：该计数器用于统计方法被调用的次数，它的默认阈值在 Client 模式下是 1500 此，在 Server 模式下是 10 000 次。可以通过虚拟机参数-XX：CompileThreshold来设定阈值。
• 回边计数器：它的作用是统计一个方法中循环体代码执行的次数。可以通过-XX: OnStackReplacePercentage来调整回边计数器的阈值。

虚拟机运行在 Client 模式下，回边计数器阈值计算公式为：

$$CompileThreshold × OnStackReplacePercentage / 100$$

其中 OnStackReplacePercentage 默认值为 933，如果都取默认值，那 Client 模式虚拟机的回边计数器的阈值为 13995。

虚拟机运行在 Server 模式下，回边计数器阈值的计算公式为：

$$CompileThreshold × (OnStackReplacePercentage - InterpreterProfilePercentage) / 100$$

其中 OnStackReplacePercentage 默认值为 140，InterpreterProfilePercentage 默认值为 33，如果都取默认值，那 Server 模式虚拟机回边计数器的阈值为 10700。

CompileThreshold: 方法调用计数器阈值
OnStackReplacePercentage: OSR 比率
InterpreterProfilePercentage: 解释器监控比率

编译过程

在默认设置下，无论是方法调用产生的即时编译请求，还是 OSR 编译请求，虚拟机在代码编译器还未完成之前，都仍然将按照解释方式继续执行，而编译动作则在后台的编译线程中进行。
用户可以通过参数 -XX: -BackgroundCompilation来禁止后台编译，在禁止后台编译后，一旦达到 JIT 的编译条件，执行线程向虚拟机提交编译请求后将会一直等待，直到编译过程完成后再开始执行编译器输出的本地代码。

查看及分析即时编译结果

一般来说，虚拟机的即时编译过程对用户程序是完成透明的，虚拟机通过解释执行代码还是编译执行代码，对于用户来说并没有什么影响（执行结果没有影响，速度上会有很大差别）。在大多数情况下用户也没有必要知道。但是虚拟机也提供了一些参数用来输出即时编译和某些优化手段（如方法内联）的执行状况。

编译优化技术

这些代码优化变换是建立在代码的某种中间表示或机器码之上，绝不是建立在Java源码之上的。

类型	优化技术
编译器策略	延时编译
	分层编译
	…
基于性能监控的优化技术	乐观空值断言
	乐观类型断言
	…
基于证据的优化技术	精确值类型推断
	内存值推断
	…
数据流敏感重写	条件常量传播
	无用代码消除
	…
语言相关的优化技术	自动装箱消除
	..