jvm(11)-晚期（运行期）优化

【0】README

0.1）本文部分文字描述转自 “深入理解 jvm”，旨在学习  晚期（运行期）优化  的基础知识；

【1】概述

1）即时编译器（JIT=just in time compiler）定义：为了提高热点代码的执行效率，在运行时，虚拟机将把这些代码编译成与 本地平台相关的机器码，并进行各种层次的优化，完成这个任务的编译器称为即时编译器；

2）热点代码：当虚拟机发现某个方法或代码块运行特别频繁，就会把这些代码认定为热点代码；（干货——即时编译器和热点代码的定义）

Attention）本文提及的编译器，即时编译器都是指HotSpot 虚拟机内的即时编译器，虚拟机也是特指HotSpot虚拟机；

【2】 HotSpot 虚拟机内的即时编译器

0）我们需要解决以下问题：

• problem1）为何HotSpot虚拟机要使用解释器与编译器并存的架构？
• problem2）为何HotSpot虚拟机要实现两个不同的即时编译器？
• problem3）程序何时使用解释器执行？何时使用编译器执行？
• problem4）哪些程序代码会被编译为本地代码？ 如何编译为本地代码？
• problem5）如何从外部观察即时编译器的编译过程和编译结果？

【2.1】解释器与编译器

1）解释器与编译器各有优势：

• 1.1）解释器的优势：当程序需要迅速启动和执行的时候，解释器可以首先发挥作用，省去编译的时间，立即执行；
• 1.2）编译器的优势：在程序运行后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码之后，可以获得更高的执行效率；
• 
  

2）HotSpot虚拟机中内置了两个即时编译器，分别为：Client Compiler 和 Server Compiler， 或简称为C1 和 C2 编译器；用于可以使用 -client 或 -server 参数去强制指定虚拟机运行在Client 模式或 Server模式；

3）混合模式：解释器和编译器搭配使用的方式在虚拟机中叫做 混合模式；（干货——虚拟机运行模式包括，混合模式+解释模式+编译模式）

• 3.1）解释模式：使用参数 -Xint 强制虚拟机运行在解释模式， 这时编译器完全不介入工作；
• 3.2）编译模式：使用参数 -Xcomp 强制虚拟机运行在编译模式， 这时将优先采用编译方式执行程序，但解释器仍然要求在编译无法进行的情况下介入执行过程；
• 3.3）通过虚拟机的 -version 命令的输出结果显示出这3种模式：
• 
  

4）分层编译：为了在程序启动相应速度与运行效率之间达到最佳平衡，HotSpot 虚拟机还会逐渐启用分层编译的策略；分层编译工具编译器编译，优化的规模与耗时，划分出不同的编译层次，包括：

• 4.1）第0层：程序解释执行，解释器不开启性能监控功能，可触发第1层编译。
• 4.2）第1层：也成为C1编译，将字节码编译为本地代码，进行简单、可靠的优化，如有必要时将加入性能监控的逻辑。
• 4.3）第2层（或2层以上）：也成为C2编译，也是将字节码编译为本地代码，但是会启动一些编译耗时较长的优化，甚至会根据性能监控信息进行一些不可靠的激进优化。 
• 4.4）事实上： 用Client Compiler获取更高的编译速度，用Server Compiler来获取更好的编译质量，在解释执行的时候也无须再承担收集性能监控信息的任务。（干货——Client Compiler 和 Server Compiler的用途）

【2.2】编译对象与触发条件

1）在运行过程中会被即时编译器编译的热点代码有两类：即：（干货——引入热点代码）

• 1.1）被多次调用的方法；
• 1.2）被多次执行的循环体；

2）JIT编译方式和OSR编译方式（干货——JIT编译方式和OSR编译方式）

2.1）JIT编译方式：对于第一种情况，由于是由方法调用触发的编译，因此编译器会以整个方法作为编译对象，这种编译也是虚拟机中标准的JIT编译方式；

2.2）OSR编译方式：尽管编译动作是由循环体所触发的，但编译器依然会以整个方法作为编译对象，这种编译方式因为编译发生在方法执行过程之中，因此形象地被称为栈上替换，简称为OSR编译，即方法栈帧还在栈上，方法就被替换了。

3）触发条件

• 3.1）问题一：被多次调用，在这里的多次具体是多少次？
• 3.2）问题二：并且虚拟机如何统计一个方法或一段代码被执行过多少次？ 
• 3.3）解决了以上问题，就回答了即时编译器被触发的条件；

4）热点探测

4.1）定义：判断一段代码是不是热点代码，是不是需要触发即时编译，这样的行为称为热点探测；

4.2）主要的热点探测判断方式（method）有两种，如下：（干货——热点探测判断方式（method））

• method1）基于采样的热点探测：虚拟机会周期性地检查各种线程的栈顶，如果发现某个或者某些方法经常出现在栈顶，那这个方法就是“热点方法”。 

优点：实现简单、高效，还可以很容易地获取方法调用方法。 

缺点：很难精确地确认一个方法的热度，因为容易受到线程阻塞或别的外界因素的影响而扰乱热点探测。

• method2）基于计数器的热点探测：虚拟机会为每个方法建立计数器，统计方法的执行次数，如果执行次数超过一定的阙值就认为它是热点方法。 

优点：统计结构相对来说更加精确与严谨。 

缺点：实现起来麻烦，需要为每个方法及建立并维护计数器，而且不能直接获取到方法的调用关系。 

5）在HotSpot中使用的是第二种方法，基于计数器的热点探测法，因此它为每个方法准备了两类计数器：方法调用计数器和回边计数器（统计一个方法中循环体代码执行的次数，在字节码中中遇到控制流向后跳转的指令称为“回边”。建立回边计数器的目的是为了触发OSR编译。）。（干货——引入方法调用计数器和回边计数器）

5.1）方法调用计数器（统计方法被调用次数）

• 5.1.1）定义：这个计数器就用于统计方法被调用的次数，他的默认阈值在 Client模式下是1500次，在 Server模式下是10000次，可以通过 虚拟机参数 -XX: CompileThreshold 来认为设定；
• Attention）JIT编译的交互过程：
  • A1）当一个方法被调用时，会先检查该方法是否存在被JIT 编译过的版本：如果存在，则优先使用编译后的本地代码来执行。如果不存在已被编译过的版本，则将此方法的调用计数器值加1，然后判断方法调用计数器与回边计数器值之和是否超过方法计数器的阈值。若超过了，则将会向即时编译器提交一个该方法的代码编译请求；
  • A2）如果不做任何设置：执行引擎并不会同步等待编译请求完成，而是继续进入解释器按照解释方式执行字节码，直到提交的请求被编译器编译完成。当编译工作完成之后，这个方法的调用入口地址就会被系统自动改写成新的，下一次调用该方法时就会使用已变异的版本，整个JIT 编译的交互过程如下图所示：
  • 
    

5.2）回边计数器（统计方法循环体代码执行次数）

• 5.2.1）作用：是统计一个方法中循环体代码执行的次数，在字节码中遇到控制流向后跳转的指令称为”回边“；显然，建立回边计数器统计的目的是为了触发OSR 编译（==栈上替换编译）；（干货——回边计数器的作用）
• 5.2.2）设置参数 -XX:OnStackReplacePercentage 来简介调整回边计数器的阈值，回边计数器的阈值的计算公式如下：
  • case1）虚拟机运行在Client模式下：阈值=方法调用计数器阈值*OSR比率/100；
  • case2）虚拟机运行在Server模式下：阈值=方法调用计数器阈值*（OSR比率-解释器监控比率）/100；
• 5.2.3）回边计数器触发即时编译的过程：当解释器遇到一条回边指令时，会先查找将要执行的代码片段是否有已经编译好的version，如果有，他将会优先执行已编译的代码，否则就把回边计数器的值加1，然后判断方法调用计数器与回边计数器之和是否超过回边计数器的阈值。当超过阈值的时候，将会提交一个OSR编译请求，并且把回边计数器的值降低一些，以便继续在解释器中执行循环，等待编译器输出编译结果，整个执行过程如下图所示：

Attention）图11-2 和 图11-3都仅仅描述了 Client VM 的即时编译技术，对于Server VM来说，case 或许还更加复杂；

【2.3】编译过程

1）无论是方法调用产生的即时编译请求，还是OSR编译请求：虚拟机在代码编译器还未完成之前，都将按照解释方式继续执行，而编译动作则在后台的编译线程中进行；

2）在后台执行编译的过程中，编译器做了什么事情呢？

3）对于Client Compiler来说，它是一个简单快速的三段式编译器；（干货——Client 编译器的编译过程）

• step1）在第一个阶段：一个平台独立的前端将字节码构造成一种高级中间代表表示（High Level Intermediate Representation,HIR）。
• step2）在第二个阶段：一个平台相关的后端从 HIR中产生低级中间代码表示（Low Level Intermediate Representation, LIR）；
• step3）在第三个阶段：最后是在平台相关的后端使用线性扫描算法在LIR 上分配寄存器，并在LIR上做窥孔优化，然后产生机器代码；
• Conclusion）整个 Client Compiler 的大致执行过程如下图所示：

4）Server Compiler：该编译器则是专门面向服务端的典型应用并为服务端的性能配置特别调整过的编译器，也是充分优化过的高级编译器，几乎能达到GNU C++ 编译器使用 -O2参数时的优化强度；

【2.4】查看及分析即时编译结果（如何从外部观察虚拟机的即时编译行为）

1）看个荔枝

// 测试JIT代码优化过程public class JITCompileResultTest {public static final int NUM = 15000;public static int doubleValue(int i) {// 这个空循环用于后面演示 JIT代码优化过程for(int j=0; j<010000; j++);return i * 2;}public static long calculateSum() {long sum = 0;for (int i = 0; i <= 100; i++) {sum += doubleValue(i);}return sum;}public static void main(String[] args) {for (int i = 0; i < NUM; i++) {calculateSum();}}}

对上述代码的分析（Analysis）： 使用参数 -XX: +PrintCompilation 要求虚拟机在即时编译时将被编译成本地代码的方法名称打印出来；

（此处有文字省略）

【3】编译优化技术

0）java程序员有一个共识：以编译方式执行本地代码比解释方式更快，之所以有这样的共识，除去虚拟机解释执行字节码时额外消耗时间的原因外，还有一个重要的原因是 虚拟机设计团队几乎把对代码的所有优化措施都集中在了即时编译器中。所以编译器产生的本地代码会比Javac 产生的字节码更加优秀；（干货——编译器产生的本地代码会比Javac 产生的字节码更加优秀）

【3.1】优化技术概览

1）看个荔枝

1.0）源代码

• step1）优化第一步，进行方法内联：主要目的有两个：一是去除方法调用的成本，二是为其他优化建立良好的基础，方法内联膨胀后可以便于在更大范围上采取后续的优化手段；
• 
  
• step2）优化第二步，进行冗余访问消除：（看成是公共子表达式的消除）
• 
  
• step3）复写传播： 因为在这段程序的逻辑中并没有必要使用一个额外的变量z，它与变量y 是完全相等的，因此可以使用 y 来代替；
• 
  
• step4）无用代码消除：无用代码可能是永远不会被执行的代码，也可能是完全没有意义的代码，因此，它又形象地称为 Dead Code；
• 
  

Conclusion）我们将继续查看如下的几项最具有代表性的优化技术是如何运作的，分别是：（干货——几项最具有代表性的编译优化技术）

• C1）公共子表达式消除；
• C2）数组范围检查消除；
• C3）方法内联；
• C4）逃逸分析；

【3.2】公共子表达式消除

1）定义：如果一个表达式E 已经计算过了，并且从先前的计算到现在，E中所有变量的值都没有发生变化，那么E 的这次出现就称为了公共子表达式；

2）看个荔枝：

2.1）如下表达式： int d = (c*b)*12 +a + (a+b*c);

2.2）当这段代码进入到虚拟机即时编译器后，它将进行如下优化：编译器检测到 c*b 与 b*c 是一样的表达式，且在计算期间b与c的值不会改变，故，这条表达式就可能被视为：  int d = E * 12 + a + (a+E);

【3.3】 数组边界检查

1）定义：在java语言中，访问数组元素的时候，系统将会自动进行上下界的范围检查，即检查i 必须满足 大于等于0且小于数组长度；否则抛出一个运行时异常： java.lang.ArrayIndexOutOfBoundsException；

2）如果编译器只要通过数据流分析就可以判定循环变量的取值范围永远在区间 [0,foo.length]内，那在整个循环中就可以吧数组的上下界检查消除；

3）problem+solution

• problem）在安全检查方面，java要比C 或C++做更多的事情，这些事情成为了一种隐式开销，如果处理不好它们，就很可能成为一个 java语言比 C/C++ 更慢的因素；
• solution）要消除这些隐式开销，其中之一还要避免思路——隐式异常处理，java中空指针检查和算术运算中除数为零的检查都采用了这种思路；（干货——隐式开销，隐式异常处理的概念）；

4）隐式开销的荔枝：

// 隐式异常处理public class ImplicitExceptionHandle {static class B {int value;}// 隐式异常优化之前的java伪代码（before）public int before_optimize() {B b = new B();if(b != null) {return b.value;} else {throw new NullPointerException();}}// 隐式异常优化之后的java伪代码（after）public int after_optimize() {try {B b = new B();return b.value;}catch(segment_fault) {uncommon_trap();}}}

【3.4】方法内联

1）定义： 把目标方法的代码“复制”到发起调用的方法之中，避免发生真实的方法调用。（干货——方法内联定义）

2）如果不是即时编译器做了一些特别的努力，按照经典编译原理的优化理论，大多数的java方法都无法进行内联；

• 2.1）无法内联的原因：只有使用 invokespecial 指令调用的私有方法， 实例构造器，父类方法以及使用invokestaitc指令进行调用的静态方法才是在编译期进行解析的，除了上述4种方法外，其他的java方法调用都需要在运行时进行方法接收者的多态选择，并且都有可能存在多于一个版本的方法接收者；简而言之，java语言中默认的实例方法是虚方法；
• 2.2）对于一个虚方法： 编译期做内联的时候根本无法确定应该使用哪个方法版本；

补充-Complementary）虚方法非虚方法与虚方法：（干货——虚方法与非虚方法定义）

• C1）非虚方法：只要能被invokestatic 和 invokespecial 指令调用的方法，都可以在解析阶段中确定唯一的调用版本，符合这个条件的有静态方法，私有方法，实例构造器，父类方法4类，他们在类加载的时候就会把符号引用解析为对该方法的直接引用。这些方法称为非虚方法；
• C2）虚方法：其他的方法称为虚方法（除去final方法）；

3）解决虚方法的内联问题

对上图的分析（Analysis）：

• A1）CHA==类型继承关系分析（Class Hierarchy Analysis, CHA）：这是一种基于整个应用程序的类型分析技术，它用于确定在目前已经加载的类中，某个接口是否有多于一种的实现，某个类是否存在子类，子类是否为抽象类等信息；
• A2）方法内联（Inline Cache）：工作原理是，在未发生方法调用之前，内联缓存状态为空，当第一次调用发生后，缓存记录下方法接收者的版本信息，并且每次进行方法调用时都比较接收者版本，如果以后进来的每次调用的方法接收者版本都是一样的，那这个内联还可以一直用下去。如果发生了方法接收者不一致的 case， 就说明程序真正使用了虚方法的多态特性，这时才会取消内联，查找虚方法表进行方法分派；

【3.5】逃逸分析

1）方法逃逸+线程逃逸 （干货——逃逸分析包括方法逃逸+线程逃逸）

• 1.1）方法逃逸：分析对象的动态作用域，当一个对象在方法中被定义后，它可能被外部方法所引用，例如作为调用参数传递给其他方法，称为方法逃逸；
• 1.2）线程逃逸：甚至还有可能被外部线程访问到，比如赋值给类变量或可以在其他线程中访问到的实例变量，称为线程逃逸；

2）如果能证明一个对象不会逃逸到方法或线程之外，即别的方法或线程无法通过任何途径访问到这个对象，则可能为这个变量进行一些高效的优化，如下所示：（干货——保证对象不逃逸到方法或线程之外，就可以进行高效优化）

• 2.1）栈上分配：如果确定一个对象不会逃逸出方法之外，那让这个对象在栈上分配内存将是一个不错的主意，对象所占用的内存空间就可以随栈帧出栈而销毁；
• 2.2）同步消除：线程同步本身是一个相对耗时的过程，如果逃逸分析能够确定一个变量不会逃逸出线程，那这个变量的读写肯定不会有竞争，对这个变量实施的同步措施就可以消除掉；
• 2.3）标量替换
  • 2.3.1）标量定义：它是指一个数据已经无法再分解成更小的数据来表示了，java虚拟机中的原始数据类型都不能再进一步分解，他们就可以成为标量；
  • 2.3.2）聚合量定义：如果一个数据可以继续分解，它被称为聚合量；
  • 2.3.3）标量替换：如果把一个java对象拆散，根据程序访问的情况，将其使用到的成员变量恢复原始类型来访问就叫做标量替换；那程序真正执行的时候，将可能不创建这个对象，而改为直接创建它的若干个被这个方法使用到的成员变量来代替。
• Attention）
  • A1）逃逸分析技术还不成熟，不推荐使用；
  • A2）不成熟的原因：无法保证逃逸分析的性能收益必定高于它的消耗；

3）如果有需要，并确认对程序运行有益，用户可以手动开启逃逸分析

• 3.1）用户使用参数 -XX: +DoEscapeAnalysis 来手动开启逃逸分析；
• 3.2）开启之后可以通过参数 -XX: +PrintEscapeAnalysis 来查看分析结果；
• 3.3）有了逃逸分析支持后，用户可以使用参数 -XX: +EliminateAllocations 来开启标量替换：
• 3.4）使用 +XX:+EliminateLocks 来开启同步消除；
• 3.5）使用参数 -XX：+PrintElimianteAllocations 查看标量的替换情况；
• Attention）尽管目前逃逸分析的技术不是很成熟，但它却是即时编译器优化技术的一个重要发展方向，在今后的虚拟机中，逃逸分析技术肯定会支撑起一些列实用有效的优化技术
• （干货——逃逸分析技术前途无量）

【4】java 与 C/C++ 的编译器对比（Comparison）

0）java虚拟机的即时编译器与C/C++ 的静态优化编译器相比，会由于以下原因而导致输出的本地代码有一些劣势：

• C1）因为即时编译器运行占用的是用户程序的运行时间：具有很大的时间压力，它能提供的优化手段严重受制于编译成本； 
• C2）java语言是动态的类型安全语言：这就意味着需要由虚拟机来确保程序不会违反语言语义后访问非结构化内存。从实现层面上来看，这就意味着虚拟机必须频繁地进行动态检查，如实例方法访问时检查空指针，数组元素访问时检查上下界访问，类型转换时检查基础关系等。总体上仍然要消耗不少的时间；
• C3）java语言中没有virtual关键字，但使用虚方法的频率却远远大于 C 或 C++：这意味着运行时对方法接收者进行多态选择的频率要远远大于C或C++，也意味着 即时编译器在进行一些优化时的难度要远远大于C 或 C++ 的静态优化编译器；
• C4）java语言是可以动态扩展的语言，运行时加载新的类可能改变程序类型的继承关系： 这使得很多全局的优化都难以进行，因为编译器无法看见程序的全貌，许多全局的优化措施都只能以激进优化的方式来完成，编译器不得不时刻注意并随着类型的变化而在运行时撤销或重新进行一些优化；
• C5）java语言中对象的内存分配都是在堆上进行的：只有方法中的局部变量才能在栈上分配；而C 或 C++的对象则有多种内存分配方式，既可能在堆上分配，也可能在栈上分配，如果可以在栈上分配线程私有的对象，将减轻内存回收的压力；另外，C或C++中主要由用户程序代码来回收分配的内存，这就不存在无用对象筛选的过程，因此在效率上，也比垃圾收集机制要高；

Conclusion）以上java的劣势并不是说 java 不如 C或C++了

• C1）java 语言上的这些性能上的劣势都是为了换取开发效率上的优势而付出的代价；动态安全， 动态扩展， 垃圾回收这些拖后腿的特性都为 java 的开发效率做出了贡献；
• C2）许多优化时 Java的即时编译器能做而C 或 C++的静态优化编译器不能做或做的不好的；
• C3）java编译器另外一个红利是由它的动态性带来的： 由于C或C++编译器所有优化都在编译器完成，以运行期性能监控为基础的优化措施它都无法进行；