JVM--后端编译与优化--大致总结

如果我们把字节码看作是程序语言的一种中间表示形式的话，那编译器无论在何时、何种状态下把Class文件转换成与本地基础设施相关的二进制机器码，都可以视为整个编译过程的后端。

1.即时编译器

• 目前主流的java虚拟机内部都同时包含解释器与编译器。当程序需要迅速启动和执行的时候，解释器可以首先发挥作用，省去编译的时间，立即运行。当程序启动后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码，这样可以减少解释器的中间损耗，获得更高的执行效率。
• 解释器与编译器经常是相辅相成地配合工作。解释器还可以作为编译器激进优化时后备的“逃生门”，如加载了新类以后，类型继承结构出现变化、出现“罕见陷阱时”可以通过逆优化退回到解释状态继续执行。

 1.1 运行模式

• 解释器与编译器配合使用的方式在虚拟机中被称为“混合模式（Mixed Mode），为默认模式
• 可以使用参数 -Xint 强制虚拟机运行于“解释模式（Interpreter Mode）”
• 可以使用参数 -Xcomp 强制虚拟机运行于“编译模式（Compiled Mode）”

1.2 HotSpot VM 内置了三个即时编译器

1. 客户端编译器（Client Compiler），简称 C1 编译器。
2. 服务端编译器（Server Compiler），简称 C2 编译器，或 Opto 编译器。
3. Graal 编译器（JDK 10 出现，长期目标是替代 C2 编译器）。

用户可以使用“-client”或“-server”参数去强制指定虚拟机运行模式。

1.3 对比分析

• 程序需要迅速启动和执行时，解释器可以省去编译时间，立即执行。
• 程序启动后，编译器逐渐发挥作用，把越来越多的代码编译成本地代码，可以减少解释器的中间消耗，提高执行效率。
• 若运行环境的内存资源限制较大，可使用解释器执行节约内存；反之可使用编译执行来提升效率。

1.4总结

• 解释器启动较快，占用内存较小，但是执行效率稍低。
• 编译器启动较慢，占用内存较大，但执行效率较高。

2.分层编译

即时编译器编译本地代码需要占用程序运行时间，解释器可能还要替编译器手机性能监控信息，这对执行阶段的速度也有影响。为了在程序启动响应速度与运行效率之间达到最佳平衡，HotSpot采用了分层编译。

1. 程序纯解释执行，且解释器不开启性能监控功能。
2. 使用 C1 编译器将字节码编译为本地代码来执行，进行简单可靠的稳定优化，不开启性能监控功能。
3. 使用 C1 编译器执行，仅开启一部分性能监控功能（方法及回边次数统计等）。
4. 使用 C1 编译器执行，开启全部性能监控（在第二层之外，还会收集如分支跳转、虚方法调用版本等全部的统计信息）。使用 C2 编译器将字节码编译为本地代码（相比 C1 编译器，C2 编译器会启用更多编译耗时更长的优化，还会根据性能监控信息进行一些不可靠的激进优化）。

3.编译对象与触发条件

3.1热点代码主要分为两类：

1. 被多次调用的方法。
2. 被多次执行的循环体。

不管是哪一类，编译器都会以整个方法作为编译对象。这种编译方式因为编译发生在方法执行的过程中，因此被很形象地称为“栈上替换”，即方法的栈帧还在栈上，方法就被替换了。

3.2热点探测的判断方式：

1. 如果发现某个方法经常出现在栈顶，那这个方法就是“热点方法”。
2. 基于计数器的热点探测。HotSpot为每个方法准备了两类计数器：方法调用计数器和回边计数器。当遇到方法入口时两个计数器的和超过了方法调用计数器的阈值或者遇到回边指令两个计数器的和超过了回边计数器的阈值时，将会向即时编译器提交一个该方法的代码编译请求，执行引擎默认异步进行，请求后会继续进入解释其按照解释其方式执行字节码。

3.3阈值

• 方法调用计数器在客户端模式下默认为1500,在服务端模式下默认为10000（可以通过-XX:CompileThreshold设定）。方法调用计数器统计不是一个绝对次数，而是一个相对频率。当超过一定时间限度，方法的调用计数器会被减少一半（称为方法调用计数器热度的衰减），而该时间称为此方法统计的半衰周期，该动作是在GC时顺便进行的。可以使用-XX:UseCounterDecay来关闭热度衰减。
• 回边计数器的作用是统计一个方法中循环体代码执行的次数。它的阈值计算公式：

客户端模式下：方法调用计数器阈值 * OSR比率（-XX:OnStackReplacePercentage设置，默认933） / 100 ，默认为13995
服务端模式下：[方法调用计数器阈值 * OSR比率 - 解释器监控比率 (-XX:InterpreterProfilePercentage,默认33) ] / 100，默认为10700

3.4流程
 

提前编译器

提前编译的两条分支：

1. 与传统C、C++编译器类似，在程序运行之前把程序代码编译成机器码的静态翻译工作。
2. 把原本即时编译器在运行时要做的编译工作提前做好并保存下来，下次运行到这些代码时直接把它加载进来。可以称为即时编译缓存。

即时编译器的优势：

• 性能分析制导优化： 根据不断收集的性能监控信息，可以根据当下实际情况应该如何分配资源或者热点代码集中优化等。
• 激进预测性优化：会根据监控的信息进行一些基于高概率假设的优化，如果出现错误(走到某个罕见的分支)了再退回解释器或者低程度的编译器，而静态优化需要保证所有程序可见外部影响和优化前一致。对于激进优化，只要正确概率足够高，那么就会大幅度降低目标程序的复杂度。比如方法的内联，Java方法是默认使用的虚方法，而每一个都查虚方法表，那是很慢的，所以需要对方法进行一些内联，激进优化就会通过猜测去做去虚拟化。
• 链接时优化：一个个Class文件在运行期被加载到虚拟机1内存当中，然后在即时编译器里产生优化后的本地代码。

编译器优化技术

方法内联

• 内联被业内称为优化之母，没有内联，多数其他优化都无法有效进行。对于一个虚方法，编译器静态地做内联的时候很难确定应该使用哪个方法版本，为了解决该问题，java虚拟机引入了一种名为类型继承关系分析（CHA）的技术：如果是非虚方法，直接内联;如果遇到虚方法，会向CHA查询是否有多个版本，如果只有一个进行内联（守护内联）。如果加载新的类型从而导致改变CHA则会进入“逃生门”退回到解释器执行的状态。
• 假设向CHA查询的结果是方法有多个版本选择，将会使用内联缓存：在未发生方法调用之前内联缓存状态为空，当第一次调用后缓存记录下方法的接收者版本信息，并且每次进行方法调用时都比较接收者的版本。如果一样，则是一种单态内联缓存，反之则会退化成多态内联缓存。

逃逸分析

逃逸程度：

1. 从不逃逸：在一个方法体中。
2. 方法逃逸：对象在方法里面被定义后，被外部方法所引用。
3. 线程逃逸：对象在方法里面被定义后，被其他线程访问看到。

优化方法：

• 栈上分配：如果对象不是线程逃逸，可以使用栈上分配对象，对象就可以随着方法出栈而销毁。
• 标量替换：如果对象从不逃逸，程序在执行时不会去创建这个对象，而是创建他被使用的成员变量来代替。
• 同步消除：如果变量不是线程逃逸，可以将其线程同步的措施消除。

公共子表达式消除

如果一个表达式E之前已经被计算过了，并且从先前的计算到现在E中所有变量的值都没有发生变化，则E的这次出现成为公共子表达式，不回对其重新计算。

数组边界检查消除

• 对于虚拟机的执行子系统来说，每次数组元素的读写都带有一次隐含的条件判断，对于拥有大量数组访问的程序代码，这必定是性能负担。
• 如果下标是一个常量且编译期可以确定数组的length，编译期则可以对其进行判断，运行时则无须执行了。
• 如果访问发生在数组中，如果编译器能够通过数据流分析判定数组访问不会越界，则会将运行时数组的上下界检查消除。
• 如果空指针和除数为0的出现此时较少，则它们的检查可以用隐式异常处理来优化，这里的异常处理是指进程层面的异常处理器，并非java的。