JVM 基础篇16 —— 编译期(三)

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

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

HotSpot虚拟机内的即时编译器

绝大部分Java虚拟机都采用解释器与编译器并存的架构。

解释器与编译器各自优点:

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

因此在整个虚拟机执行架构中,解释器与编译器经常是相辅相成地配合工作的

HotSpot虚拟机中内置了两个即时编译器,称为Client CompilerServer Compiler,简称为C1编译器和C2编译器(也叫Opto编译器)。目前主流的HotSpot虚拟机中,默认是采用解释器与其中一个编译器直接配合的方式工作,程序使用哪个编译器,取决于虚拟机运行的模式,HotSpot虚拟机会根据自身版本与宿主机器的硬件性能自动选择运行模式,用户也可以使用-client-server参数去强制指定虚拟机运行在Client模式还是Server模式。

解释器与编译器搭配使用的方式在虚拟机中被称为**“混合模式”(Mixed Mode**),用户可以使用参数-Xint强制虚拟机运行于“解释模式”(Interpreted Mode)。另外,也可以使用参数-Xcomp强制虚拟机运行于“编译模式”(Compiled Mode),这时候将优先采用编译方式执行程序,但是解释器仍然要在编译无法进行的情况下介入执行过程,可以通过虚拟机的-version命令的输出结果显示出这三种模式

分层编译

即时编译器编译本地代码需要占用程序运行时间,要编译出优化程度更高的代码,所花费的时间可能越长;而且想要编译出优化程度更高的代码,解释器可能还要替编译器收集性能监控信息,这对解释执行的速度也有所影响。为了在程序启动响应速度与运行效率之间达到最佳平衡,HotSpot虚拟机将会逐渐启用分层编译(Tiered Compilation)的策略

划分层次:

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

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

编译对象与触发条件

前面提到过在运行过程中会被即时编译器编译的“热点代码”有两类,即:

  • 被多次调用的方法。

    • 由于是由方法调用触发的编译,那编译器理所当然地会以整个方法作为编译对象,这种编译也是虚拟机中标准的编译方式。
  • 被多次执行的循环体。

    • 尽管编译动作是由循环体所触发的,但编译器依然会以整个方法(而不是单独的循环体)作为编译对象。这种编译方式因为编译发生在方法执行过程之中,因此被很形象地称为栈上替换(On Stack Replacement, OSR)

判断一段代码是不是热点代码,是不是需要触发即时编译的操作称为热点探测(Hot Spot Detection),热点探测并不一定要知道方法具体被调用了多少次,目前主要的热点探测判定方式有两种,分别是:

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

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

在HotSpot虚拟机中使用的是第二种—基于计数器的热点探测方法,因此它为每个方法准备了两个计数器:方法调用计数器(Invocation Counter)回边计数器(Back Edge Counter)。这两个计数器都有一个确定的阈值,当计数器超过阈值溢出了,就会触发JIT编译。

方法调用计数器

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

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

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

回边计数器

用于统计一个方法中循环体代码执行的次数,在字节码中遇到控制流向后跳转的指令就称为“回边(Back Edge)”,建立回边计数器统计的目的就是为了触发OSR编译。

关于回边计数器的阈值,虽然HotSpot虚拟机也提供了一个类似于方法调用计数器阈值-XX:CompileThreshold的参数-XX:BackEdgeThreshold供用户设置,但是当前的虚拟机实际上并未使用此参数,因此我们需要设置另外一个参数-XX:OnStackReplacePercentage来间接调整回边计数器的阈值.

Client模式下,回边计数器阈值计算公式为:

方法调用计数器阈值(CompileThreshold)乘以OSR比率(OnStackReplacePercentage)除以100。其中OnStackReplacePercentage默认值为933,如果都取默认值,那Client模式虚拟机的回边计数器的阈值为13995。

Server模式下,回边计数器阈值的计算公式为:

方法调用计数器阈值(CompileThreshold)乘以(OSR比率(OnStackReplacePercentage)减去解释器监控比率(InterpreterProfilePercentage)的差值)除以100。其中OnStackReplacePercentage默认值为140,InterpreterProfilePercentage默认值为33,如果都取默认值,那Server模式虚拟机回边计数器的阈值为10700。

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

Client Compiler

在后台执行编译的过程中,Client Compiler主要的关注点在于局部性的优化,而放弃了许多耗时较长的全局优化手段。其步骤如下:

  1. 一个平台独立的前端将字节码构造成一种高级中间代码表示(High-Level Intermediate Representaion, HIR)。HIR使用静态单分配(Static SingleAssignment, SSA)的形式来代表代码值,这可以使得一些在HIR的构造过程之中和之后进行的优化动作更容易实现。在此之前编译器会在字节码上完成一部分基础优化,如方法内联、常量传播等优化将会在字节码被构造成HIR之前完成。

  2. 一个平台相关的后端从HIR中产生低级中间代码表示(Low-Level Intermediate Representation, LIR),而在此之前会在HIR上完成另外一些优化,如空值检查消除、范围检查消除等,以便让HIR达到更高效的代码表示形式。

  3. 平台相关的后端使用线性扫描算法(Linear Scan Register Allocation)在LIR上分配寄存器,并在LIR上做窥孔(Peephole)优化,然后产生机器代码。

Server Compiler

Server Compiler专门面向服务端的典型应用并为服务端的性能配置特别调整过的编译器,也是一个充分优化过的高级编译器,几乎能达到GNU C++编译器使用-O2参数时的优化强度,它会执行所有的经典的优化动作,如:无用代码消除(Dead Code Elimination)循环展开(Loop Unrolling)循环表达式外提(Loop Expression Hoisting)、公共子表达式消除(Common Subexpression Elimination)常量传播(Constant Propagation)基本块重排序(Basic Block Reordering)等,还会实施一些与Java语言特性密切相关的优化技术,如范围检查消除(Range Check Elimination)空值检查消除(Null Check Elimination,不过并非所有的空值检查消除都是依赖编译器进行优化的,有一些是在代码运行过程中自动优化了)等。另外,还可能根据解释器或Client Compiler提供的性能监控信息进行一些不稳定的激进优化,如守护内联(Guarded Inlining)分支频率预测(Branch Frequency Prediction) 等。

Server Compiler的寄存器分配器是一个全局图着色分配器,它可以充分利用某些处理器架构(如RISC)上的大寄存器集合。以即时编译的标准来看,Server Compiler无疑是比较缓慢的,但它的速度仍然远远超过传统的静态优化编译器,而且它相对于Client Compiler编译输出的代码质量有所提高,可以减少本地代码的执行时间,从而抵消了额外的编译时间开销,所以也有很多非服务端的应用选择使用Server模式的虚拟机运行。

查看与分析即时编译结果

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

首先我们可以通过使用参数-XX:+PrintCompilation要求虚拟机在即时编译时将被编译成本地代码的方法名称打印出来.并且可以加上参数-XX:+PrintInlining要求虚拟机输出方法内联信息。

除了查看哪些方法被编译之外,还可以进一步查看即时编译器生成的机器码内容,不过如果虚拟机输出一串0和1,对于我们的阅读来说是没有意义的,机器码必须反汇编成基本的汇编语言才可能被阅读。虚拟机提供了一组通用的反汇编接口,可以接入各种平台下的反汇编适配器来使用,如使用x86平台则选用hsdis-i386,hsdis-amd64适配器。(其余平台的适配器还有如、hsdis-sparc和hsdis-sparcv9等),可以下载或自己编译出反汇编适配器后,将其放置在JRE/bin/client或/servier目录下,只要与jvm.dll的路径相同即可被虚拟机调用。为虚拟机安装了反汇编适配器之后,就可以使用-XX:+PrintAssembly参数要求虚拟机打印编译方法的汇编代码了如果没有hsdis支持,也可以使用-XX:printOptoAssembly(用于Server VM)或-XX:+print LIR(用于Client VM)来输出比较接近最终结果的中间代码表示。

更进一步除了本地代码的生成结果外,还想再进一步跟踪本地代码生成的具体过程,那还可以使用参数-XX:+PrintCFGToFile(使用Client Compiler)或-XX:PrintIdealGraphFile(使用Server Compiler)令虚拟机将编译过程中各个阶段的数据(如对C1编译器来说包括:字节码、HIR生成、LIR生成、寄存器分配过程、本地代码生成等数据)输出到文件中。然后使用Java HotSpot Client Compiler Visualizer(使用Client Compiler)或Ideal Graph Visualizer(使用Server Compiler)打开这些数据文件进行分析.

实际使用的时候请注意,要输出CFG或IdealGraph文件,需要一个Debug版的虚拟机支持,Product版或FastDebug版的虚拟机无法输出这些文件。前面提到的使用-XX:+PrintAssembly参数输出反汇编信息也需要FastDebug版的虚拟机才能直接支持,如果使用Product版的虚拟机,则需要加入参数-XX:+UnlockDiagnosticVMOptions打开虚拟机诊断模式后才能使用。

更新时间:2020-09-01 21:53:59

本文由 寻非 创作,如果您觉得本文不错,请随意赞赏
采用 知识共享署名4.0 国际许可协议进行许可
本站文章除注明转载/出处外,均为本站原创或翻译,转载前请务必署名
原文链接:https://www.zhouning.group/archives/jvm基础篇16编译期三
最后更新:2020-09-01 21:53:59

评论

Your browser is out of date!

Update your browser to view this website correctly. Update my browser now

×