第十一章后端编译与优化-CSDN博客

本文链接：https://blog.csdn.net/flyingmylife/article/details/135528415

文章目录

11.1 概述
11.2 即时编译器
11.3 提前编译器
11.4 编译器优化技术

11.1 概述

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

无论是提前编译器抑或即时编译器，都不是 Java 虚拟机必需的组成部分。后端编译器编译性能的好坏、代码优化质量的高低却是衡量一款商用虚拟机优秀与否的关键指标之一。

11.2 即时编译器

目前主流的两款商用 Java 虚拟机（HotSpot、 OpenJ9）里， Java 程序最初都是通过解释器（Interpreter）进行解释执行的，当虚拟机发现某个方法或代码块的运行特别频繁，就会把这些代码认定为“热点代码”（Hot Spot Code），为了提高热点代码的执行效率，在运行时，虚拟机将会把这些代码编译成本地机器码，并以各种手段尽可能地进行代码优化，运行时完成这个任务的后端编译器被称为即时编译器。

需要解决一下几个问题：

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

11.2.1 解释器与编译器

【这段话重要！！！】

当程序需要迅速启动和执行的时候，解释器可以首先发挥作用，省去编译的时间，立即运行。当程序启动后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码，这样可以减少解释器的中间损耗，获得更高的执行效率。当程序运行环境中内存资源限制较大，可以使用解释执行节约内存（如部分嵌入式系统中和大部分的 JavaCard 应用中就只有解释器的存在），反之可以使用编译执行来提升效率。同时，解释器还可以作为编译器激进优化时后备的“逃生门”（如果情况允许， HotSpot 虚拟机中也会采用不进行激进优化的客户端编译器充当“逃生门”的角色），让编译器根据概率选择一些不能保证所有情况都正确，但大多数时候都能提升运行速度的优化手段，当激进优化的假设不成立，如加载了新类以后，类型继承结构出现变化、出现“罕见陷阱”（Uncommon Trap）时可以通过逆优化（ Deoptimization）退回到解释状态继续执行，因此在整个 Java 虚拟机执行架构里，解释器与编译器经常是相辅相成地配合工作。

HotSpot 虚拟机中内置了两个（或三个）即时编译器，其中有两个编译器存在已久，分别被称为“客户端编译器”（Client Compiler）和“服务端编译器”（ServerCompiler），或者简称为 C1 编译器和 C2 编译器（部分资料和 JDK 源码中 C2 也叫 Opto编译器），第三个是在 JDK 10 时才出现的、长期目标是代替 C2 的 Graal 编译器， Graal编译器目前还处于实验状态。

在分层编译（Tiered Compilation）的工作模式出现以前， HotSpot 虚拟机通常是采用解释器与其中一个编译器直接搭配的方式工作。

程序使用哪个编译器，只取决于虚拟机运行的模式， HotSpot 虚拟机会根据自身版本与宿主机器的硬件性能自动选择运行模式，用户也可以使用“-client”或“-server”参数去强制指定虚拟机运行在客户端模式还是服务端模式。

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

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

实施分层编译后，解释器、客户端编译器和服务端编译器就会同时工作，热点代码都可能会被多次编译，用客户端编译器获取更高的编译速度，用服务端编译器来获取更好的编译质量，在解释执行的时候也无须额外承担收集性能监控信息的任务，而在服务端编译器采用高复杂度的优化算法时，客户端编译器可先采用简单优化来为它争取更多的编译时间。

11.2.2 编译对象与触发条件

1.什么是热点代码：

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

前者很好理解，一个方法被调用得多了，方法体内代码执行的次数自然就多，它成为“热点代码”是理所当然的。而后者则是为了解决当一个方法只被调用过一次或少量的几次，但是方法体内部存在循环次数较多的循环体，这样循环体的代码也被重复执行多次，因此这些代码也应该认为是“热点代码”。

对于这两种情况，编译的目标对象都是整个方法体，而不会是单独的循环体。第一种情况，由于是依靠方法调用触发的编译，那编译器理所当然地会以整个方法作为编译对象，这种编译也是虚拟机中标准的即时编译方式。

而对于后一种情况，尽管编译动作是由循环体所触发的，热点只是方法的一部分，但编译器依然必须以整个方法作为编译对象，只是执行入口（从方法第几条字节码指令开始执行）会稍有不同，编译时会传入执行入口点字节码序号（Byte Code Index， BCI）。这种编译方式因为编译发生在方法执行的过程中，因此被很形象地称为**“栈上替换”**（On Stack Replacement，OSR），即方法的栈帧还在栈上，方法就被替换了。

2.目前主流的热点探测

基于采样的热点探测

采用这种方法的虚拟机会周期性地检查各个线程的调用栈顶，如果发现某个（或某些）方法经常出现在栈顶，那这个方法就是“热点方法”。

优点：简单高效

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

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

优点：精确

缺点：比较麻烦

3.两类计数器（基于上面的第二种）

方法调用计数器
- 计数器就是用于统计方法被调用的次数默认阈值在客户端模式下是 1500 次，在服务模式下是 10000 次，这个阈值可以通过虚拟机参数-XX： CompileThreshold 来人为设定

在这里插入图片描述
2. 回边计数器

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

11.2.3 编译过程

在默认条件下，无论是方法调用产生的标准编译请求，还是栈上替换编译请求，虚拟机在编译器还未完成编译之前，都仍然将按照解释方式继续执行代码，而编译动作则在后台的编译线程中进行。

后台编译过程：

1.对于客户端编译器来说，有以下三个阶段：

一个平台独立的前端将字节码构造成一种高级中间代码表示
一个平台相关的后端从 HIR 中产生低级中间代码表示（ Low-Level Intermediate Representation， LIR，即与目标机器指令集相关的中间表示），而在此之前会在 HIR 上完成另外一些优化，如空值检查消除、范围检查消除等，以便让 HIR 达到更高效的代码表示形式。
在平台相关的后端使用线性扫描算法（ Linear Scan Register Allocation）在 LIR 上分配寄存器，并在 LIR 上做窥孔（Peephole）优化，然后产生机器代码。

2.对于服务端

服务端编译器则是一个能容忍很高优化复杂度的高级编译器，几乎能达到 GNUC++编译器使用-O2 参数时的优化强度。它会执行大部分经典的优化动作，如：无用代码消除（Dead Code Elimination）、循环展开（ Loop Unrolling）、循环表达式外提（Loop Expression Hoisting）、消除公共子表达式（Common Subexpression Elimination）、常量传播（Constant Propagation）、基本块重排序（Basic Block Reordering）等，还会实施一些与 Java 语言特性密切相关的优化技术，如范围检查消除（Range Check Elimination）、空值检查消除（Null Check Elimination，不过并非所有的空值检查消除都是依赖编译器优化的，有一些是代码运行过程中自动优化了）等。

另外，还可能根据解释器或客户端编译器提供的性能监控信息，进行一些不稳定的预测性激进优化，如守护内联（ GuardedInlining）、分支频率预测（Branch Frequency Prediction）等。

11.3 提前编译器

两个分支：

1.做与传统 C、C++编译器类似的，在程序运行之前把程序代码编译成机器码的静态翻译工作；

2.把原本即时编译器在运行时要做的编译工作提前做好并保存下来，下次运行到这些代码（譬如公共库代码在被同一台机器其他 Java 进程使用）时直接把它加载进来使用。本质是给即时编译器做缓存加速。

11.4 编译器优化技术

编译器的目标虽然是做由程序代码翻译为本地机器码的工作，但其实难点并不在于能不能成功翻译出机器码，输出代码优化质量的高低才是决定编译器优秀与否的关键。

技术预览在p413，下面主要介绍几个重要的方法。

11.4.1 方法内联

内联被业内戏称为优化之母，因为除了消除方法调用的成本之外，它更重要的意义是为其他优化手段建立良好的基础。

方法内联的优化行为理解起来是没有任何困难的，不过就是把目标方法的代码原封不动地“复制”到发起调用的方法之中，避免发生真实的方法调用而已。

例子：

public static void foo(Object obj) {
	if (obj != null) {
		System.out.println("do something");
	}
}
public static void testInline(String[] args) {
	Object obj = null;
	foo(obj);
}

但是有些方法是不能够内联的，无法内联的原因其实在第 8 章中讲解 Java 方法解析和分派调用的时候就已经解释过：只有使用 invokespecial 指令调用的私有方法、实例构造器、父类方法和使用invokestatic 指令调用的静态方法才会在编译期进行解析。

对于一个虚方法，编译器静态地去做内联的时候很难确定应该使用哪个方法版本，以将代码清单 11-7 中所示 b.get()直接内联为 b.value 为例，如果不依赖上下文，是无法确定 b 的实际类型是什么的。

为了解决虚方法的内联问题， Java 虚拟机首先引入了一种名为类型继承关系分析（Class Hierarchy Analysis， CHA）的技术，这是整个应用程序范围内的类型分析技术，用于确定在目前已加载的类中，某个接口是否有多于一种的实现、某个类是否存在子类、某个子类是否覆盖了父类的某个虚方法等信息。

类型继承关系方案：

非虚方法：直接进行内联就可以了，这种的内联是有百分百安全保障的；

虚方法：向 CHA 查询此方法在当前程序状态下是否真的有多个目标版本可供选择，如果查询到只有一个版本，那就可以假设“应用程序的全貌就是现在运行的这个样子”来进行内联，这种内联被称为守护内联（Guarded Inlining）。因为Java是动态链接的程序，例如可能临时产生一个代理类，就需要设置好“逃生门”，说不准什么时候就会有不同的方法，就需要退回到解释执行的状态。

如果确实有多个版本的目标方法，编译器会做**内联缓存（Inline Cache）**的方式来缩减方法调用的开销。这样会比直接查CHA快一些。

工作原理：在未发生方法调用之前，内联缓存状态为空，当第一次调用发生后，缓存记录下方法接收者的版本信息，并且每次进行方法调用时都比较接收者的版本。如果以后进来的每次调用的方法接收者版本都是一样的，那么这时它就是一种单态内联缓存（ Monomorphic Inline Cache）。

所以说，在多数情况下 Java 虚拟机进行的方法内联都是一种激进优化。

11.4.2 逃逸分析

1.基本原理

分析对象动态作用域，当一个对象在方法里面被定义后，它可能被外部方法所引用，例如作为调用参数传递到其他方法中，这种称为方法逃逸；甚至还有可能被外部线程访问到，譬如赋值给可以在其他线程中访问的实例变量，这种称为线程逃逸；从不逃逸、方法逃逸到线程逃逸，称为对象由低到高的不同逃逸程度。

如果能证明一个对象不会逃逸到方法或线程之外（换句话说是别的方法或线程无法通过任何途径访问到这个对象），或者逃逸程度比较低（只逃逸出方法而不会逃w逸出线程），则可能为这个对象实例采取不同程度的优化，如：

栈上分配

如果确定一个对象不会逃逸出线程之外，那让这个对象在栈上分配内存将会是一个很不错的主意，对象所占用的内存空间就可以随栈帧出栈而销毁。栈上分配可以支持方法逃逸，但不能支持线程逃逸。
标量替换

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

假如逃逸分析能够证明一个对象不会被方法外部访问，并且这个对象可以被拆散，那么程序真正执行的时候将可能不去创建这个对象，而改为直接创建它的若干个被这个方法使用的成员变量来代替。

但对逃逸程度的要求更高，它不允许对象逃逸出方法范围内
同步消除

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