晚期（运行期）优化

• 热点代码（Hot Spot Code）：运行得特别频繁的某个方法或代码块
  • 被多次调用的方法。
  • 被多次执行的循环体。
• 即时编译器（Just In Time Compiler，简称JIT编译器）：为了提高热点代码的效率，在运行时，把这些代码编译成与本地平台相关的机器码，并进行各种层次的优化的编译器

HotSpot虚拟机内的即时编译器

解释器与编译器

当程序需要迅速启动和执行的时候，解释器可以首先发挥作用，省去编译的时间，立即执行。在程序运行后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码之后，可以获取更高的执行效率。

图1 解释器和编译器的交互

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

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

编译对象与触发条件

• 热点代码

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

• 热点探测

  • 判断一段代码是不是热点代码，是不是需要触发即时编译的行为
  • 基于采样的热点探测（Sample Based Hot Spot Detection）
    • 虚拟机会周期性地检查各个线程的栈顶，如果发现某个（或某些）方法经常出现在栈顶，那这个方法就是“热点方法”。
  • 基于计数器的热点探测（Counter Based Hot Spot Detection）
    • 虚拟机会为每个方法（甚至是代码块）建立计数器，统计方法的执行次数，如果执行次数超过一定的阈值就认为它是“热点方法”。

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

• 方法调用计数器
  • 用于统计方法被调用的次数，它的默认阈值在Client模式下是1500次，在Server模式下是10 000次

  • 当一个方法被调用时，会先检查该方法是否存在被JIT编译过的版本，如果存在，则优先使用编译后的本地代码来执行。 如果不存在已被编译过的版本，则将此方法的调用计数器值加1，然后判断方法调用计数器与回边计数器值之和是否超过方法调用计数器的阈值。 如果已超过阈值，那么将会向即时编译器提交一个该方法的代码编译请求。

    
    
    图2 方法调用计数器触发即时编译
  • 方法调用计数器热度的衰减
    • 当超过一定的时间限度，如果方法的调用次数仍然不足以让它提交给即时编译器编译，那这个方法的调用计数器就会被减少一半，这段时间就称为此方法统计的半衰周期（Counter Half Life Time）
• 回边计数器
  • 统计一个方法中循环体代码执行的次数
  • 回边：在字节码中遇到控制流向后跳转的指令
  • 建立回边计数器统计的目的就是为了触发OSR编译
  • 虚拟机运行在Client模式下，回边计数器阈值计算公式为：
    • 方法调用计数器阈值（CompileThreshold）×OSR比率（OnStackReplacePercentage）/100。其中OnStackReplacePercentage默认值为933，如果都取默认值，那Client模式虚拟机的回
      边计数器的阈值为13995。
  • 虚拟机运行在Server模式下，回边计数器阈值的计算公式为：
    • 方法调用计数器阈值（CompileThreshold）×（OSR比率（OnStackReplacePercentage）-解释器监控比率（InterpreterProfilePercentage）/100。其中OnStackReplacePercentage默认值为140，InterpreterProfilePercentage默认值为33，如果都取默认值，那Server模式虚拟机回边计数器的阈值为10700。

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

    
    
    图3 回边计数器触发即时编译
  • 与方法计数器不同，回边计数器没有计数热度衰减的过程，因此这个计数器统计的就是该方法循环执行的绝对次数。 当计数器溢出的时候，它还会把方法计数器的值也调整到溢出状态，这样下次再进入该方法的时候就会执行标准编译过程。
• 在确定虚拟机运行参数的前提下，这两个计数器都有一个确定的阈值，当计数器超过阈值溢出了，就会触发JIT编译。

编译过程

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

  
  
  图4 Client Compiler架构

Server Compiler则是专门面向服务端的典型应用并为服务端的性能配置特别调整过的编译器，也是一个充分优化过的高级编译器，几乎能达到GNU C++编译器使用-O2参数时的优化强度。另外，还可能根据解释器或Client Compiler提供的性能监控信息，进行一些不稳定的激进优化，如守护内联（Guarded Inlining）、 分支频率预测（Branch Frequency Prediction）等。

• Server Compiler的寄存器分配器是一个全局图着色分配器，它可以充分利用某些处理器架构（如RISC）上的大寄存器集合。

编译优化技术

虚拟机设计团队几乎把对代码的所有优化措施都集中在了即时编译器之中

公共子表达式消除

如果一个表达式E已经计算过了，并且从先前的计算到现在E中所有变量的值都没有发生变化，那么E的这次出现就成为了公共子表达式。 对于这种表达式，没有必要花时间再对它进行计算，只需要直接用前面计算过的表达式结果代替E就可以了。

数组边界检查消除

隐式异常处理

方法内联

消除方法调用的成本之外，并其他优化手段建立良好的基础
“类型继承关系分析”（Class Hierarchy Analysis,CHA）：
是一种基于整个应用程序的类型分析技术，它用于确定在目前已加载的类中，某个接口是否有多于一种的实现，某个类是否存在子类、 子类是否为抽象类等信息。

• 编译器在进行内联时，如果是非虚方法，直接进行内联
• 如果遇到虚方法，则会向CHA查询此方法在当前程序下是否有多个目标
  版本可供选择。
  • 如果查询结果只有一个版本，那也可以进行内联，不过这种内联就属于激进优化，需要预留一个“逃生门”（Guard条件不成立时的Slow Path），称为守护内联（Guarded Inlining）。 如果程序的后续执行过程中，虚拟机一直没有加载到会令这个方法的接收者的继承关系发生变化的类，那这个内联优化的代码就可以一直使用下去。 但如果加载了导致继承关系发生变化的新类，那就需要抛弃已经编译的代码，退回到解释状态执行，或者重新进行编译。
  • 如果向CHA查询出来的结果是有多个版本的目标方法可供选择，则编译器还将会进行最后一次努力，使用内联缓存（Inline Cache）来完成方法内联，这是一个建立在目标方法正常入口之前的缓存，它的工作原理大致是：在未发生方法调用之前，内联缓存状态为空，当第一次调用发生后，缓存记录下方法接收者的版本信息，并且每次进行方法调用时都比较接收
    者版本，如果以后进来的每次调用的方法接收者版本都是一样的，那这个内联还可以一直用下去。 如果发生了方法接收者不一致的情况，就说明程序真正使用了虚方法的多态特性，这时才会取消内联，查找虚方法表进行方法分派。

逃逸分析

分析对象动态作用域：当一个对象在方法中被定义后，它可能被外部方法所引用，例如作为调用参数传递到其他方法中，称为方法逃逸。 甚至还有可能被外部线程访问到，譬如赋值给类变量或可以在其他线程中访问的实例变量，称为线程逃逸。

• 栈上分配（Stack Allocation）：如果确定一个对象不会逃逸出方法之外，那让这个对象在栈上分配内存将会是一个很不错的主意。由于HotSpot虚拟机目前的实现方式导致栈上分配实现起来比较复杂，因此在HotSpot中暂时还没有做这项优化。
• 同步消除（Synchronization Elimination）：线程同步本身是一个相对耗时的过程，如果逃逸分析能够确定一个变量不会逃逸出线程，无法被其他线程访问，那这个变量的读写肯定就不会有竞争，对这个变量实施的同步措施也就可以消除掉。
• 标量替换（Scalar Replacement）：标量（Scalar）是指一个数据已经无法再分解成更小的数据来表示了，Java虚拟机中的原始数据类型（int、 long等数值类型以及reference类型等）都不能再进一步分解，它们就可以称为标量。 相对的，如果一个数据可以继续分解，那它就称作聚合量（Aggregate），Java中的对象就是最典型的聚合量。 如果把一个Java对象拆散，根据程序访问的情况，将其使用到的成员变量恢复原始类型来访问就叫做标量替换。 如果逃逸分析证明一个对象不会被外部访问，并且这个对象可以被拆散的话，那程序真正执行的时候将可能不创建这个对象，而改为直接创建它的若干个被这个方法使用到的成员变量来代替。

Java与C/C++的编译器对比

劣势：

• 第一，因为即时编译器运行占用的是用户程序的运行时间，具有很大的时间压力，它能提供的优化手段也严重受制于编译成本。
• 第二，Java语言是动态的类型安全语言，这就意味着需要由虚拟机来确保程序不会违反语言语义或访问非结构化内存。
• 第三，Java语言中虽然没有virtual关键字，但是使用虚方法的频率却远远大于C/C++语言，这意味着运行时对方法接收者进行多态选择的频率要远远大于C/C++语言，也意味着即时编译器在进行一些优化（如前面提到的方法内联）时的难度要远大于C/C++的静态优化编译器。
• 第四，Java语言是可以动态扩展的语言，运行时加载新的类可能改变程序类型的继承关系，这使得很多全局的优化都难以进行。
• 第五，Java语言中对象的内存分配都是堆上进行的，只有方法中的局部变量才能在栈上分配。

优势 ：

• 在C/C++中，别名分析（Alias Analysis）的难度就要远高于Java。
• Java编译器另外一个红利是由它的动态性所带来的，由于C/C++编译器所有优化都在编译期完成，以运行期性能监控为基础的优化措施它都无法进行，如调用频率预测（Call Frequency Prediction）、 分支频率预测（Branch Frequency Prediction）、 裁剪未被选择的分支（Untaken Branch Pruning）等，这些都会成为Java语言独有的性能优势。