JVM-12.即时编译器

=

完成以上任务的编译器被称为即时编译器（Just In Time Compiler，JIT编译器）。

1. HotSpot中的JIT编译器

1.1 编译器和解释器

• HotSpot中有编译器和解释器并存。
• HotSpot中内置两个JIT编译器：
  • JVM根据自身版本和机器硬件性能自动选择
  • Client Compiler，简称C1，-client参数强制
  • Server Compiler，简称C2， -server参数强制
• 解释器和编译器搭配使用成为混合模式（Mixed Mode）
  • 用-Xint参数强制JVM运行与解释模式，全部用解释方式，编译器不介入
  • 用-Xcomp强制JVM运行于编译模式，优先采用编译方式
• 分层编译：根据比那一起编译，优化的规模耗时，划分出不同的编译层次
  • 第0层，程序解释执行，解释器不开启性能监测功能，触发第一层编译
  • 第1层，也叫C1编译，将字节码编译为本地代码，进行简单， 可靠的优化，如有必要，加入性能监测的逻辑
  • 第2层（或者2层以上），也叫C2编译，将字节码比那一位本地代码，但会开启一些编译耗时较长的优化，甚至根据性能监控信息进行一些不可靠的激进优化
  • 分层编译后，Client Compiler和Server Compiler将会同时工作，代码可能会被多次编译，用Client获得更高的编译速度，用Server获得更好的编译质量，解释执行的时候无需搜集性能监控信息

1.2 编译对象和触发条件

• 热点代码有两类：
  • 多次调用的方法
  • 多次执行的循环体，实际上也会以整个方法作为编译对象
• 判断热点的方法主要有两种：
  • 基于采样的热点探测（Sample Based Hot Spot Detection）：周期性检查各个线程的栈顶，发现某个（某些）方法经常出现在栈顶，就是热点方法
    • 有点简单高效，可以获取方法调用关系（将调用堆栈展开即可）
    • 缺点是很难精确确认方法热度，容易受到线程阻塞等外界因素影响
  • 基于计数器的热点探测（Counter Based Hot Spot Detection）：为每个方法（甚至代码块）建立计数器，统计方法调用次数，如果执行超过阈值就认为是热点方法。缺点是实现较为困难。优点是结果更精确。
• 基于计数器的探测：
  • Client模式下默认1500次，Server下默认10000次，根据参数-XX:CompileThreshold设定。
  • 调用一个方法，先检查是否存在JIT编译版本本地代码，存在优先使用本地代码，不存在将计数器加1。然后判断调用计数器和回边计数器之和是否大于阈值，如果超过，用JIT编译器提交编译请求。JIT编译完成后方法调用入口就被系统换成新的。下次调用已编译版本。
  • 计数器热度衰减（Counter Decay超过一定的时间限度，方法的调用次数仍未达到阈值，方法计数器减少一半。在垃圾收集期间执行，用-UseCounterDecay来关闭，以统计绝对次数。用-XX:CounterHalfLifeTime设置半半衰周期。
• 回边计数器：统计方法中方法体代码执行的次数，在字节码中遇到控制流向后跳动的指令成为回边（Back Edge）。
  • 回边计数器阈值可以用-XX:OnStackReplacePercentage来间接调整。
  • 回边计数器没有热度衰减过程。

1.3 编译过程

• JVM默认情况下对于即时编译请求在编译完成之前，都按照解释方式执行，编译动作在后台线程执行
• 参数-XX:-BackgroundCompilation禁止后台编译，此时编译请求会等待，直到编译完成后直接执行本地代码
• Client Compiler：关注局部优化，简单快速，放弃耗时的长时优化
• Server Compiler：面向服务端，高性能，复杂，较缓慢