"In-depth understanding of java virtual machine" study notes TEN - Chapter XI

Chapter XI of late (run-time) optimization

Time compilation in 1, HotSpot Virtual Machine

Interpreters and compilers:

Many Java virtual machine execution engine in the implementation of Java code are interpreted (executed by an interpreter) compile and execute (native code produced by the compiler instant) two options

Time compiler:

When a virtual machine running a discovery method particularly frequent or code blocks, the code will be recognized as a hotspot code. In order to improve the efficiency of the hot code. Virtual chance at run time code compiled to platform-dependent machine code, and various levels of optimization, this task is called a compiler-time compiler (Just In Time Compiler, hereinafter referred to as the JIT compiler).

Both interpreters and compilers have their own advantages:

When the program needs to quickly launch and execution, the interpreter can first play, eliminating the need for time to compile, execute immediately. After running the program, over time, gradually play a role in the compiler, after putting more and more code is compiled to native code, can achieve higher efficiency.
When the program operating environment more limited memory resources (e.g., partially embedded systems) may be executed using an interpreter to save memory, whereas the compiler can be used to improve the efficiency of execution.
At the same time, the interpreter can also serve as a time of aggressive compiler optimization "escape hatch" to let the compiler choose some means most of the time can be optimized to enhance the speed of the probability, when aggressive optimization assumption does not hold, such as loading a new class can be returned to by inverse optimization (Deoptimization) after type inheritance structure changes, a "rare trap" (uncommon trap) to explain the state to continue.
No part of the virtual machine interpreter will also adopt a radical C1 compiler does not optimize assume the role of "escape door", (in a virtual machine in the habit of the Client Compiler called C1, called the Server Compiler C2) Therefore, the entire virtual machine execution architecture, compilers and interpreters often work together.

HotSpot virtual machine that is time compiler:

HotSpot virtual machine built into the two-time compiler, called Client Compiler and Server Compiler, or simply C1 and C2 compiler compiler.
目前主流的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）来输出比较接近最终结果的中间代码表示。

2、编译优化技术

概述：

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

公共子表达式消除：

如果一个表达式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对象拆散，根据程序访问的情况，将其使用到的成员变量恢复原始类型来访问就叫做标量替换。如果逃逸分析证明一个对象不会被外部访问，并且这个对象可以被拆散的话，那程序真正执行的时候将可能不创建这个对象，而改为直接创建它的若干个被这个方法使用到的成员变量来代替。将对象拆分后，除了可以让对象的成员变量在栈上（栈上存储的数据，有很大的概率会被虚拟机分配至物理机器的高速寄存器中存储）分配和读写之外，还可以为后续进一步的优化手段创建条件。

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

https://www.cnblogs.com/AmyZheng/p/10565957.html

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

1、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），这时编译器完全不介入工作，全部代码都使用解释方式执行。