如果我们把字节码看作是语言程序的一种中间表示形式，那编译器无论在何时、在何种状态下把Class文件转换成与本地基础设施（硬件指令集、操作系统）相关的二进制机器码，它都可以视为整个编译过程的后端。虽然无论是提前编译器还是即时编译器，都不是Java虚拟机必须的组成部分，但后端编译器编译性能的好坏、代码优化质量的高低却是衡量一款商用虚拟机优秀与否的关键指标之一。

HotSpot虚拟机内的即时编译

即时编译器

当虚拟机发现某个方法或者代码块的运行特别频繁时，就会把这些代码认定为热点代码。为了提高热点代码的执行效率。在运行时虚拟机会把这些代码编译成本地平台相关的机器码，并进行各种层次的优化，完成这个任务的编译器称为即时编译器（Just In Time Compiler，下文中简称JIT编译器）。

HotSpot虚拟机中即时间编译器：

  • HotSpot虚拟机中内置了两个即时编译器，分别称为客户端编译器（Client Compiler）和服务器端编译器（Server Compiler），或者简称为C1编译器和C2编译器（还有一个旨在代替C2的Graal编译器，但目前仍处于实验状态）。
  • 在分层编译（具体请看下文）的工作模式出现之前，HotSpot虚拟机默通常是采用解释器与其中一个编译器直接配合的方式工作，程序使用哪个编译器，取决于虚拟机运行的模式，HotSpot虚拟机会根据自身版本与宿主机器的硬件性能自动选择运行模式，用户也可以使用“-client”或“-server”参数去强制指定虚拟机运行在Client模式或Server模式。
  • 无论采用的编译器是Client Compiler还是Server Compiler，解释器与编译器搭配使用的方式在虚拟机中称为“混合模式”（Mixed Mode），用户可以使用参数“-Xint”强制虚拟机运行于“解释模式”（Interpreted Mode），这时编译器完全不介入工作，全部代码都使用解释方式执行

解释器与编译器

目前主流的商用Java虚拟机（Hotspot、OpenJ9等），内部都同时包含解释器和编译器，解释器和编译器两者各有优势：

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

因此，在整个虚拟机执行架构中，解释器与编译器经常配合工作，如下图所示。

image-20210618211744581

分层编译策略

即时编译器编译本地代码需要占用程序运行时间（通常要编译出优化程度越高的代码，所花费的时间便会越长）。而且想要编译出优化程度更高的代码，解释器可能还要替编译器搜集性能监控信息，这也会影响解释执行阶段的速度。

为了在程序响应速度和运行效率之间达到最佳平衡，HotSpot虚拟机在编译子系统中加入了分层编译功能。

分层编译根据编译器编译、优化的规模和耗时，划分出不同的编译层次：

  • 第0层，程序解释执行，解释器不开启性能监控功能（Profiling），可触发第1层编译。
  • 第1层，使用客户端编译器将字节码编译为本地代码，进行简单、可靠的优化，不开启性能监控功能。
  • 第2层，仍然使用客户端编译器执行，仅开启方法及回边次数统计等有限的性能监控功能。。
  • 第3层，仍然使用客户端编译器执行，开启全部性能监控，除了第二层的统计信息外，还会收集如分支跳转、虚方法调用版本等全部的统计信息。
  • 第4层，使用服务端编译器执行，相比起客户端编译器，它会启用更多编译耗时更长的优化，还会根据性能监控信息进行一些不可靠的激进优化。

以上层次并不是固定不变的，根据不同的运行参数和版本，虚拟机可以调整分层的数量。各层次编译之间的交互、转换关系如下图所示。

image-20210618214644579

编译对象和触发条件

在运行过程中会被即时编译器编译的“热点代码”有两类，被多次调用的方法和被多次执行的循环体。

这两种情况编译的目标对象都是整个方法体，而不会是单独的循环体。对于后一种情况，虽然编译器以整个方法作为编译对象，但执行入口（从方法第几条字节码指令开始执行）会稍有不同。

判断一段代码是不是热点代码，是不是需要触发即时编译，这样的行为称为热点探测（Hot Spot Detection）。目前主要的热点探测判定方式有两种，基于采样的热点探测和基于计数器的热点探测

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

基于计数器的热点探测有两种计数器，方法调用计数器（Invocation Counter）和回边计数器（Back Edge Counter）。在确定虚拟机运行参数的前提下，这两个计数器都有一个确定的阈值，当计数器超过阈值溢出了，就会触发JIT编译。

方法调用计数器：

  • 这个计数器就用于统计方法被调用的次数，它的默认阈值在Client模式下是1500次，在Server模式下是10000次，这个阈值可以通过虚拟机参数-XX：CompileThreshold来人为设定。

  • 当一个方法被调用时，会先检查该方法是否存在被JIT编译过的版本，如果存在，则优先使用编译后的本地代码来执行。如果不存在已被编译过的版本，则将此方法的调用计数器值加1，然后判断方法调用计数器与回边计数器值之和是否超过方法调用计数器的阈值。如果已超过阈值，那么将会向即时编译器提交一个该方法的代码编译请求。如果不做任何设置，执行引擎并不会同步等待编译请求完成，而是继续进入解释器按照解释方式执行字节码，直到提交的请求被编译器编译完成。当编译工作完成之后，这个方法的调用入口地址就会被系统自动改写成新的，下一次调用该方法时就会使用已编译的版本。

  • 如果不做任何设置，方法调用计数器统计的并不是方法被调用的绝对次数，而是一个相对的执行频率，即一段时间之内方法被调用的次数。当超过一定的时间限度，如果方法的调用次数仍然不足以让它提交给即时编译器编译，那这个方法的调用计数器就会被减少一半，这个过程称为方法调用计数器热度的衰减（Counter Decay），而这段时间就称为此方法统计的半衰周期（Counter Half Life Time）。进行热度衰减的动作是在虚拟机进行垃圾收集时顺便进行的，可以使用虚拟机参数-XX：-UseCounterDecay来关闭热度衰减，让方法计数器统计方法调用的绝对次数，这样，只要系统运行时间足够长，绝大部分方法都会被编译成本地代码。另外，可以使用-XX：CounterHalfLifeTime参数设置半衰周期的时间，单位是秒。

    image-20210619103028104

回边计数器：

  • 它的作用是统计一个方法中循环体代码执行的次数,准确地说，应当是回边的次数而不是循环次数，因为并非所有的循环都是回边，如空循环实际上就可以视为自己跳转到自己的过程，因此并不算作控制流向后跳转，也不会被回边计数器统计。在字节码中遇到控制流向后跳转的指令称为“回边”（Back Edge）。显然，建立回边计数器统计的目的就是为了触发OSR编译。

  • 关于回边计数器的阈值，可以通过设置参数-XX：OnStackReplacePercentage来间接调整回边计数器的阈值，其计算公式请看P394。

  • 当解释器遇到一条回边指令时，会先查找将要执行的代码片段是否有已经编译好的版本，如果有，它将会优先执行已编译的代码，否则就把回边计数器的值加1，然后判断方法调用计数器与回边计数器值之和是否超过回边计数器的阈值。当超过阈值的时候，将会提交一个OSR编译请求，并且把回边计数器的值降低一些，以便继续在解释器中执行循环，等待编译器输出编译结果。

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

    image-20210619102822230

编译过程

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

客户端编译（Client Compiler）过程分为三个阶段，主要的关注点在于局部性的优化，而放弃了很多耗时较长全局优化手段。

  • 在第一个阶段，一个平台独立的前端将字节码构造成一种高级中间代码表示（High-Level 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）优化，然后产生机器代码。
image-20210619103255979

服务端编译（Server Compiler）过程。

  • Server Compiler则是专门面向服务端的典型应用场景，并为服务端的性能配置特别调整过的编译器，也是一个充分优化过的高级编译器，几乎能达到GNU C++编译器使用-O2参数时的优化强度，它会执行大部分经典的优化动作。
  • Server Compiler无疑是比较缓慢的，但它的编译速度依然远远超过传统的静态优化编译器，而且它相对于Client Compiler编译输出的代码质量有所提高，可以减少本地代码的执行时间，从而抵消了额外的编译时间开销，所以也有很多非服务端的应用选择使用Server模式的虚拟机运行。

提前编译

目前提前编译产品和对其的研究有着两条明显分支：

  • 一条分支是做与传统C编译器类似的，在程序运行之前把程序代码编译成机器码的静态翻译工作。这是传统的提前编译应用形式，它在Java中存在的价值直指即时编译器的最大弱点：即时编译要占用程序运行时间和运算资源。
  • 另一条分支是把原本即时编译器在运行时要做的编译工作提前做好并保存下来，下次运行到这些代码时（譬如公共库代码被同一台机器其他Java进程使用）直接把它加载进来使用。其本质是给即时编译器做缓存加速，去改善Java程序的启动时间，以及需要一段时间预热后才能到达最高性能的问题。

尽管即时编译在时间和运算资源方面的劣势是无法忽视的，但其依然有自己的优势（P407）：

  • 性能分析制导优化
  • 激进预测性优化
  • 链接时优化

编译优化技术

以编译方式执行本地代码比解释方式更快的原因是，虚拟机解释执行字节码额外消耗时间，虚拟机设计团队几乎把对代码的所有优化措施都集中在了即时编译器之中。

本节介绍的几种经典的代码优化技术：方法内联、逃逸分析、公共子表达式消除 、数组范围检查消除 。（更多优化技术种类请看P412）

方法内联

方法内联可以去除方法调用的成本（如建立栈帧等），还可以为其他优化建立良好的基础（因此被戏称为优化之母）

Java语言中默认的实例方法是虚方法。对于一个虚方法，编译期做内联的时候根本无法确定应该使用哪个方法版本，Java虚拟机引入了一种名为“类型继承关系分析”（Class Hierarchy Analysis,CHA）的技术。

  • 如果遇到虚方法，则会向CHA查询此方法在当前程序下是否有多个目标版本可供选择。

  • 如果查询结果只有一个版本，那也可以进行内联，不过这种内联就属于激进优化，需要预留一个“逃生门”（Guard条件不成立时的Slow Path），称为守护内联（Guarded Inlining）。如果程序的后续执行过程中，虚拟机一直没有加载到会令这个方法的接收者的继承关系发生变化的类，那这个内联优化的代码就可以一直使用下去。但如果加载了导致继承关系发生变化的新类，那就需要抛弃已经编译的代码，退回到解释状态执行，或者重新进行编译。

  • 如果向CHA查询出来的结果是有多个版本的目标方法可供选择，则编译器还将会进行最后一次努力，使用内联缓存（Inline Cache）来完成方法内联，这是一个建立在目标方法正常入口之前的缓存.

  • 内联缓存工作原理大致是：在未发生方法调用之前，内联缓存状态为空，当第一次调用发生后，缓存记录下方法接收者的版本信息，并且每次进行方法调用时都比较接收者版本，如果以后进来的每次调用的方法接收者版本都是一样的，那这个内联还可以一直用下去。如果发生了方法接收者不一致的情况，就说明程序真正使用了虚方法的多态特性，这时才会取消内联，查找虚方法表进行方法分派。

逃逸分析

逃逸分析（Escape Analysis）不是直接优化代码的手段，是为其他优化手段提供依据的分析技术。逃逸分析的基本行为就是分析对象动态作用域：当一个对象在方法中被定义后，它可能被外部方法所引用，

  • 例如作为调用参数传递到其他方法中，称为方法逃逸。
  • 甚至还有可能被外部线程访问到，譬如赋值给类变量或可以在其他线程中访问的实例变量，称为线程逃逸。

如果能证明一个对象不会逃逸到方法或线程之外（也就是别的方法或线程无法通过任何途径访问到这个对象），或者逃逸程度比较低（只逃逸出方法而不会逃逸出线程），则可能为这个变量进行一些高效的优化：

  • 栈上分配（Stack Allocation），如果确定一个对象不会逃逸出线程之外，那让这个对象在栈上分配内存，对象就会随着方法的结束而自动销毁了，垃圾收集系统的压力将会小很多。栈上分配可以支持方法逃逸，但不能支持线程逃逸。
  • 同步消除（Synchronization Elimination），如果逃逸分析能够确定一个变量不会逃逸出线程，无法被其他线程访问，那这个变量的读写肯定就不会有竞争，对这个变量实施的同步措施也就可以消除掉。
  • 标量替换（Scalar Replacement），标量是指一个数据已经无法再分解成更小的数据来表示了，Java虚拟机中的原始数据类型（int、long等数值类型以及reference类型等）都不能再进一步分解，它们就可以称为标量。相对的，如果一个数据可以继续分解，那它就称作聚合量（Aggregate），Java中的对象就是最典型的聚合量。如果把一个Java对象拆散，根据程序访问的情况，将其使用到的成员变量恢复原始类型来访问就叫做标量替换。如果逃逸分析证明一个对象不会被外部访问，并且这个对象可以被拆散的话，那程序真正执行的时候将可能不创建这个对象，而改为直接创建它的若干个被这个方法使用到的成员变量来代替。将对象拆分后，除了可以让对象的成员变量在栈上（栈上存储的数据，有很大的概率会被虚拟机分配至物理机器的高速寄存器中存储）分配和读写之外，还可以为后续进一步的优化手段创建条件。标量替换可以视作栈上分配的一种特例，实现更简单（不用考虑整个对象完整结构的分配），但对逃逸程度的要求更高，它不允许对象逃逸出方法范围。

公共子表达式消除

如果一个表达式E已经计算过了，并且从先前的计算到现在E中所有变量的值都没有发生变化，那E的这次出现就成为了公共子表达式。

例：int d = (c * b) * 12 + a + (a + b * c) => int d = E * 12 + a + (a + E) =>int d = E * 13 + a*2。

数组边界检查消除

数组边界检查消除是即时编译器中的一项语言相关的经典优化技术。

如果有一个数组foo[]，在Java语言中访问数组元素foo[i]的时候系统将会自动进行上下界的范围检查，对于有大量数组访问的程序代码，无疑是一种性能负担。为了安全，数组边界检查肯定是要做的，但它是不是必须在运行期间一次不漏地进行则是可以“商量”的事情。

  • 例如，数组下标是一个常量，如foo[3]，只要在编译器根据数据流分析来确定foo.length的值，并确定“3”没有越界，执行的时候就无须判断了。
  • 如果数组访问发生在循环之中，并且使用循环变量来进行数组的访问，如果编译器只要通过数据流分析就可以判定循环变量的取值范围在区间[0, foo.length)之内，那么在循环中就可以把整个数组的上下界检查消除掉，这可以节省很多次的条件判断操作。