深入理解JVM学习笔记——第十一章 晚期（运行期）优化

注：本系列文章均摘录自《深入理解Java虚拟机：JVM高级特性与最佳实践》，作者周志明，我看的是第一版，现在第二版已经出了，

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

    1.为了提高热点代码的执行效率，在运行时，虚拟机会把这些代码编译成与本地平台相关的机器码，并进行各种层次的优化，完成这个任务的编译器称为及时编译器（Just In Time Compiler）。

    2.解释器还可以作为编译器激进优化时的一个“逃生门”，让编译器根据概率选择一些大多数时候都能提升运行速度的优化手段，当激进优化的假设不成立，如加载了新类后类型继承结构出现变化、出现“罕见陷阱”（Uncommon Trap）时可以通过逆优化（Deoptimization）退回到解释状态继续执行（部分没有解释器的虚拟机中也会采用不进行激进优化的C1编译器担任“逃生门”的角色）。

    3.HotSpot虚拟机中内置了两个即时编译器，称为Client Compiler和Server Compiler。或者简称为C1编译器和C2编译器（也叫Opto编译器）。HotSpot会根据自身版本与宿主机器的硬件性能自动选择运行模式，用户也可以使用-client或-server参数去强制指定虚拟机运行在Client模式还是Server模式。

    4.无论采用的编译器是Client Compiler还是Server Compiler，解释器与编译器搭配使用的方式在虚拟机中被称为“混合模式”（Mixed Mode），用户可以使用参数-Xint强制虚拟机运行于“解释模式”（Interpreted Mode），这时候编译器完全不介入工作，全部代码都使用解释方式执行。另外，也可以使用参数-Xcomp强制虚拟机运行于“编译模式”（Compiled Mode），这时候将优先采用编译方式执行程序，但是解释器仍然要在编译无法进行的情况下接入执行过程，可以通过虚拟机的-version命令的输出结果显示出这三种模式。

    5.分层编译根据编译器编译、优化的规模与耗时，划分出不同的编译层次，其中包括：

    （1）第0层：程序解释执行，解释器不开始性能监控功能（Profiling），可触发第1层编译。

    （2）第1层：也称为C1编译，将字节码编译为本地代码，进行简单可靠的优化，如有必要将加入性能监控的逻辑。

    （3）第2层（或2层以上）：也称为C2编译，也是将字节码编译为本地代码，但是会启用一些编译耗时较长的优化，甚至会根据性能监控信息进行一些不可靠的激进优化。

    6.在运行过程中会被即时编译器编译的“热点代码”有两类：

    （1）被多次调用的方法

    （2）被多次执行的循环体

    7.要知道一段代码是不是热点代码，是不是需要触发即时编译，这个行为称为热点探测（Hot Spot Detection）。其实进行热点探测并不一定知道方法具体被调用了多少次。

    主要的探测判定方式有两种：

    （1）基于采样的热点探测（Sample Base Hot Spot Detection）:虚拟机周期性地检测各个线程的栈顶，如果发现某个（或某些）方法经常出现在栈顶，那这个方法就是“热点方法”。

    （2）基于计数器的热点探测（Counter Based Hot Spot Detection）：采用这种方法的虚拟机会为每个方法（甚至是代码块）建立计数器，统计方法的执行次数，如果执行次数超过一定的阈值就认为它是“热点方法”。

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

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

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

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

    由于HotSpot提供的参数-XX:BackEdgeThreshold暂未实际使用，因此需要设置-XX：OnStackReplacePercentage来间接调整回边计数器的阈值，其计算公式为：

    （1）虚拟机运行在Client模式下，回边计数器阈值计算公式为：方法调用计数器阈值（CompileThreshold）乘以OSR比率（OnStackReplacePercentage）除以100.其中OnStackReplacePercentage默认值为933，如果都取默认值，那Client模式虚拟机回边数的阈值为13995。

    （2）虚拟机运行在Server模式下，回边计数器阈值的计算公式为：方法调用计数器阈值（CompileThreshold）乘以（OSR比率（OnStackReplacePercentage）减去解释器监控比率（InterpreterProfilePercentage）的差值）除以100。其中OnStackReplacePercentage默认值为140，InterpreterProfilePercentage默认值为33，如果都取默认值，那Server模式虚拟机回边计数器的阈值为10700。

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

    10.在默认设置下，无论是方法调用产生的即时编译请求，还是OSR编译请求，虚拟机在代码编译器还未完成之前，都仍然将按照解释的方式继续执行，而编译动作则在后台的编译线程中进行。用户可通过参数-XX：BackgroundCompilation来禁止后台编译，禁止后台编译后，当达到JIT编译条件，执行线程向虚拟机提交编译请求后将会一直等待，直到编译过程完成后在开始执行编译器输出的本地编码。

    11.对于Client Compiler来说，它是一个简单快速的三段式编译器，主要关注点在局部性的优化，而放弃了许多耗时较长的全局优化手段。

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

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

    （3）最后的阶段是在平台相关的后端使用线性扫描算法（Linear Scan Register Allocation）在LIR上分配寄存器，并在LIR上做窥孔（Peephole）优化，然后产生机器代码。

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

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

    13.“方法内联（Method Inlining）”的主要目的有两个：一是去除方法调用的成本（如建立栈帧等），二是为其他优化建立良好的基础。

    14.“公共子表达式消除”的含义是：如果有一个表达式E已经被计算过了，并且从先前的计算到现在E中所有变量的值都没有发生变化，那么E的这次出现就成为公共子表达式，没有必要花时间再对它进行计算，只需要直接用前面计算过的表达式结果代替E就可以了。如果这种优化仅局限于程序的基本块内，便称为局部公共子表达式消除（Local Common Subexpression Elimination），如果这种优化的范围涵盖了多个基本块，那就称为全局公共子表达式消除（Global Common Subexpression Elimination）。

    15.为了解决虚方法的内联问题，Java虚拟机设计团队想了很多办法，首先是引入了一种名为“类型继承关系分析”（Class Hierarchy Analysis，CHA）的技术，这是一种基于整个应用程序的类型分析技术，它用于确定在目前已经加载的类中，某个接口是否有多于一种的实现，某个类是否存在子类且子类是否为抽象类等信息。

    16.逃逸分析（Escape Analysis）是目前Java虚拟机中比较前沿的优化技术，它与类型继承关系分析一样，并不是直接优化代码的手段，而是为其他优化手段提供依据的分析技术。

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

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

    （1）栈上分配（Stack Allocations）：如果确定一个对象不会逃逸出方法之外，那让这个对象在栈上分配内存将会是一个很不错的主意，对象所占用的内存空间就可以随栈帧出栈而销毁。

    （2）同步消除（Synchronization Elimination）：线程同步本身就是一个相对耗时的过程，如果逃逸分析能够确定一个变量不会逃逸出线程，无法被其他线程访问，那这个变量的读写肯定就不会有竞争，对这变量实施的同步措施也就可以消除掉。

    （3）标量替换（Scalar Replacement）：标量（Scalar）是指一个数据已经无法再分解成更小的数据来表示了，Java虚拟机中的原始数据类型（int、long等数值类型及reference类型等）都不能再进一步分解，它们就可以被称为标量。相对的，如果一个数据可以继续分解，那它就被称做聚合量（Aggregate），Java中的对象就是最典型的聚合量。如果把一个Java对象拆散，根据程序访问的情况，将其使用到的成员变量恢复原始类型来访问就叫做标量替换。

    17.如果有需要，并且确认对程序运行有益，用户可以使用参数-XX:+DoEscapeAnalysis来手动开启逃逸分析，开启之后可以通过参数-XX:+PrintEscapeAnalysis来查看分析结果，另外，用户可以使用参数-XX:+ElminateAllocations来开启标量替换，使用参数-XX:+EliminateLock来开启同步消除，使用参数-XX:+PrintEliminateAllocations来查看标量的替换情况。