《深刻理解Java虚拟机》读书笔记十

第十一章  晚期（运行期）优化

一、HotSpot虚拟机内的即时编译

解释器与编译器：

• 许多Java虚拟机的执行引擎在执行Java代码的时候都有解释执行（经过解释器执行）和编译执行（经过即时编译器产生本地代码）两种选择

即时编译器：

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

解释器与编译器二者各有优点：

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

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

•  HotSpot虚拟机中内置了两个即时编译器，分别称为Client Compiler和Server Compiler，或者简称为C1编译器和C2编译器。
• 目前主流的HotSpot虚拟机（Sun系列JDK 1.7及以前版本的虚拟机）中，默认采用解释器与其中一个编译器直接配合的方式工做，程序使用哪一个编译器，取决于虚拟机运行的模式，HotSpot虚拟机会根据自身版本与宿主机器的硬件性能自动选择运行模式，用户也可使用“-client”或“-server”参数去强制指定虚拟机运行在Client模式或Server模式。
• 不管采用的编译器是Client Compiler仍是Server Compiler，解释器与编译器搭配使用的方式在虚拟机中称为“混合模式”（Mixed Mode），用户可使用参数“-Xint”强制虚拟机运行于“解释模式”（Interpreted Mode），这时编译器彻底不介入工做，所有代码都使用解释方式执行。

 HotSpot虚拟机的分层编译策略：

• 为了在程序启动响应速度与运行效率之间达到最佳平衡，HotSpot虚拟机还会逐渐启用分层编译（Tiered Compilation）
• 分层编译根据编译器编译、优化的规模与耗时，划分出不一样的编译层次
• 第0层，程序解释执行，解释器不开启性能监控功能（Profiling），可触发第1层编译。
• 第1层，也称为C1编译，将字节码编译为本地代码，进行简单、可靠的优化，若有必要将加入性能监控的逻辑。
• 第2层（或2层以上），也称为C2编译，也是将字节码编译为本地代码，可是会启用一些编译耗时较长的优化，甚至会根据性能监控信息进行一些不可靠的激进优化。

编译对象：

• 在运行过程当中会被即时编译器编译的“热点代码”有两类，被屡次调用的方法和被屡次执行的循环体。
• 被屡次调用的方法，整个方法做为编译对象。被屡次执行的循环体，尽管编译动做是由循环体所触发的，但编译器依然会以整个方法（而不是单独的循环体）做为编译对象。这种编译方式由于编译发生在方法执行过程之中，所以形象地称之为栈上替换（On Stack Replacement，简称为OSR编译，即方法栈帧还在栈上，方法就被替换了）。

触发条件：

• 判断一段代码是否是热点代码，是否是须要触发即时编译，这样的行为称为热点探测（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参数设置半衰周期的时间，单位是秒。

回边计数器：

• 它的做用是统计一个方法中循环体代码执行的次数,准确地说，应当是回边的次数而不是循环次数，由于并不是全部的循环都是回边，如空循环实际上就能够视为本身跳转到本身的过程，所以并不算做控制流向后跳转，也不会被回边计数器统计。（在字节码中遇到控制流向后跳转的指令称为“回边”（Back Edge）。显然，创建回边计数器统计的目的就是为了触发OSR编译。
• 关于回边计数器的阈值，能够经过设置参数-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编译请求，而且把回边计数器的值下降一些，以便继续在解释器中执行循环，等待编译器输出编译结果。                                                          

 

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

编译过程：

• 不管是方法调用产生的即时编译请求，仍是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）优化，而后产生机器代码。
• Server Compiler过程，Server Compiler则是专门面向服务端的典型应用并为服务端的性能配置特别调整过的编译器，也是一个充分优化过的高级编译器，几乎能达到GNU C++编译器使用-O2参数时的优化强度，它会执行全部经典的优化动做。Server Compiler无疑是比较缓慢的，但它的编译速度依然远远超过传统的静态优化编译器，并且它相对于Client Compiler编译输出的代码质量有所提升，能够减小本地代码的执行时间，从而抵消了额外的编译时间开销，因此也有不少非服务端的应用选择使用Server模式的虚拟机运行。

查看及分析即时编译结果：

• 使用参数-XX：+PrintCompilation要求虚拟机在即时编译时将被编译成本地代码的方法名称打印出来，（其中带有“%”的输出说明是由回边计数器触发的OSR编译）。
• 参数-XX：+PrintInlining要求虚拟机输出方法内联信息。
• 使用-XX+PrintOptoAssembly（用于Server VM）或-
• XX：+PrintLIR（用于Client VM）来输出比较接近最终结果的中间代码表示。

二、编译优化技术

概述：

• 以编译方式执行本地代码比解释方式更快的缘由是，虚拟机解释执行字节码额外消耗时间，虚拟机设计团队几乎把对代码的全部优化措施都集中在了即时编译器之中。
• 代码优化技术：公共子表达式消除 、数组范围检查消除 、方法内联、逃逸分析。

公共子表达式消除：

• 若是一个表达式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。

数组边界检查消除：

• 在Java语言中访问数组元素foo[i]的时候系统将会自动进行上下界的返回检查，对于有大量数组访问的程序代码，无疑是一种性能负担。在编译期根据数据流分析来判断没有越界，执行的时候就无需判断了。另外一种方法叫作隐式异常处理以下：

  if（foo！=null）{ return foo.value； }else{ throw new NullPointException（）； }

  在使用隐式异常优化以后，虚拟机会把上面伪代码所表示的访问过程变为以下伪代码。

  try{ return foo.value； }catch（segment_fault）{ uncommon_trap（）； }

  虚拟机会注册一个Segment Fault信号的异常处理器（伪代码中的uncommon_trap（）），这样当foo不为空的时候，对value的访问是不会额外消耗一次对foo判空的开销的。代价就是当foo真的为空时，必须转入到异常处理器中恢复并抛出NullPointException异常，这个过程必须从用户态转到内核态中处理，结束后再回到用户态，速度远比一次判空检查慢。当foo极少为空的时候，隐式异常优化是值得的，但假如foo常常为空的话，这样的优化反而会让程序更慢，还好HotSpot虚拟机足够“聪明”，它会根据运行期收集到的Profile信息自动选择最优方案。

方法内联：

• 方法内联能够去除方法调用的成本（如创建栈帧等），还能够为其余优化创建良好的基础
• Java语言中默认的实例方法是虚方法。对于一个虚方法，编译期作内联的时候根本没法肯定应该使用哪一个方法版本，Java虚拟机引入了一种名为“类型继承关系分析”（Class Hierarchy Analysis,CHA）的技术，若是遇到虚方法，则会向CHA查询此方法在当前程序下是否有多个目标版本可供选择，若是查询结果只有一个版本，那也能够进行内联，不过这种内联就属于激进优化，须要预留一个“逃生门”（Guard条件不成立时的Slow Path），称为守护内联（Guarded Inlining）。
• 若是程序的后续执行过程当中，虚拟机一直没有加载到会令这个方法的接收者的继承关系发生变化的类，那这个内联优化的代码就能够一直使用下去。
• 但若是加载了致使继承关系发生变化的新类，那就须要抛弃已经编译的代码，退回到解释状态执行，或者从新进行编译。
• 若是向CHA查询出来的结果是有多个版本的目标方法可供选择，则编译器还将会进行最后一次努力，使用内联缓存（Inline Cache）来完成方法内联，这是一个创建在目标方法正常入口以前的缓存.
• 内联缓存工做原理大体是：在未发生方法调用以前，内联缓存状态为空，当第一次调用发生后，缓存记录下方法接收者的版本信息，而且每次进行方法调用时都比较接收者版本，若是之后进来的每次调用的方法接收者版本都是同样的，那这个内联还能够一直用下去。若是发生了方法接收者不一致的状况，就说明程序真正使用了虚方法的多态特性，这时才会取消内联，查找虚方法表进行方法分派。

逃逸分析：

• 逃逸分析（Escape Analysis）是为其余优化手段提供依据的分析技术。逃逸分析的基本行为就是分析对象动态做用域：当一个对象在方法中被定义后，它可能被外部方法所引用.
• 例如做为调用参数传递到其余方法中，称为方法逃逸。甚至还有可能被外部线程访问到，譬如赋值给类变量或能够在其余线程中访问的实例变量，称为线程逃逸。若是能证实一个对象不会逃逸到方法或线程以外，也就是别的方法或线程没法经过任何途径访问到这个对象，则可能为这个变量进行一些高效的优化，如栈上分配（Stack Allocation），同步消除（Synchronization Elimination），标量替换（Scalar Replacement）。
• 栈上分配，若是肯定一个对象不会逃逸出方法以外，那让这个对象在栈上分配内存，对象就会随着方法的结束而自动销毁了，垃圾收集系统的压力将会小不少。
• 同步消除，若是逃逸分析可以肯定一个变量不会逃逸出线程，没法被其余线程访问，那这个变量的读写确定就不会有竞争，对这个变量实施的同步措施也就能够消除掉。
• 标量替换，标量（Scalar）是指一个数据已经没法再分解成更小的数据来表示了，Java虚拟机中的原始数据类型（int、long等数值类型以及reference类型等）都不能再进一步分解，它们就能够称为标量。相对的，若是一个数据能够继续分解，那它就称做聚合量（Aggregate），Java中的对象就是最典型的聚合量。若是把一个Java对象拆散，根据程序访问的状况，将其使用到的成员变量恢复原始类型来访问就叫作标量替换。若是逃逸分析证实一个对象不会被外部访问，而且这个对象能够被拆散的话，那程序真正执行的时候将可能不建立这个对象，而改成直接建立它的若干个被这个方法使用到的成员变量来代替。将对象拆分后，除了可让对象的成员变量在栈上（栈上存储的数据，有很大的几率会被虚拟机分配至物理机器的高速寄存器中存储）分配和读写以外，还能够为后续进一步的优化手段建立条件。

转载请于明显处标明出处:

http://www.javashuo.com/article/p-ssoivhzp-y.html