深入理解JVM3-2-程序编译与代码优化-后端编译与优化

JVM PV:

概述

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

后面所提及的即时编译器都是特指HotSpot虚 拟机内置的即时编译器，虚拟机也是特指HotSpot虚拟机。

即时编译器

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

解释器与编译器

目前主流的商用Java虚拟 机，譬如HotSpot、OpenJ9等，内部都同时包含解释器与编译器。

解释器与编译器两者各有优势：

当程序需要迅速启动和执行的时候，解释器可以首先发挥作用，省去编译的时间，立即运行。当程序启动后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码，这样可以减少解释器的中间损耗，获得更高的执行效率。当程序运行环境中内存资源限制较大，可以使用解释执行节约内存（如部分嵌入式系统中和大部分的JavaCard应用中就只有解释器的存在），反之可以使用编译执行来提升效率。

同时，解释器还可以作为编译器激进优化时后备的“逃生门”，让编译器根据概率 选择一些不能保证所有情况都正确，但大多数时候都能提升运行速度的优化手段，当激进优化的假设 不成立，如加载了新类以后，类型继承结构出现变化、出现“罕见陷阱”（Uncommon Trap）时可以通过逆优化（Deoptimization）退回到解释状态继续执行。

编译器与解释器的交互关系如图：

解释器编译器交互

HotSpot虚拟机中内置了三个即时编译器:

  • 客户端编译器（Client Compiler、C1编译器）
  • 服务端编译器（Server Compiler、C2编译器）
  • Graal编译器（实验状态）

在分层编译（Tiered Compilation）的工作模式出现以前，HotSpot虚拟机通常是采用解释器与其中 一个编译器直接搭配的方式工作，程序使用哪个编译器，只取决于虚拟机运行的模式。（用户也可以使用“-client”或“-server”参数去强制指定虚拟机运行在客户端模式还是服务端模式）。

默认状态下，解释器与编译器搭配使用的方式在虚拟机中被称为“混合模式”（Mixed Mode）。也可以使用启动参数进行修改：

  • -Xint：强制虚拟机运行于“解释模 式”（Interpreted Mode）。
  • -Xcomp：强制虚拟机运行于“编译模式”（Compiled Mode）。

可以通过虚拟机的“version”命令的输出结果显示出这三种模式。如

1
2
3
4
5
6
7
8
9
10
11
12
13
14
C:\Users\MW>java -version
java version "16.0.2" 2021-07-20
Java(TM) SE Runtime Environment (build 16.0.2+7-67)
Java HotSpot(TM) 64-Bit Server VM (build 16.0.2+7-67, mixed mode, sharing)

C:\Users\MW>java -Xint -version
java version "16.0.2" 2021-07-20
Java(TM) SE Runtime Environment (build 16.0.2+7-67)
Java HotSpot(TM) 64-Bit Server VM (build 16.0.2+7-67, interpreted mode, sharing)

C:\Users\MW>java -Xcomp -version
java version "16.0.2" 2021-07-20
Java(TM) SE Runtime Environment (build 16.0.2+7-67)
Java HotSpot(TM) 64-Bit Server VM (build 16.0.2+7-67, compiled mode, sharing)

上面说到解释器与编译器各自的优缺点，如：

  • 由于即时编译器编译本地代码需要占用程序运行时间，通常要编译出优化程度越高的代码，所花费的时间便会越长。
  • 而且想要编译出优化程度更高的代码，解释器可能还要替编译器收集性能监控信 息，这对解释执行阶段的速度也有所影响。

所以为了在程序启动响应速度与运行效率之间达到最佳平衡， HotSpot虚拟机在编译子系统中加入了分层编译的功能。（分层编译的概念其实很早就已经提出，但 直到JDK 6时期才被初步实现，后来一直处于改进阶段，最终在JDK 7的服务端模式虚拟机中作为默认编译策略被开启）

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

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

以上层次并不是固定不变的，根据不同的运行参数和版本，虚拟机可以调整分层的数量。

各层次编译之间的交互、转换关系如图所示：

分层编译的交互关系

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

编译对象与触发条件

首先明确热点代码主要包括两类：

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

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

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

关于多次的定义，上面看起来是一个模糊的概念，必须要一个定量的定义。

要知道某段代码是不是热点代码，是不是需要触发即时编译，这个行为称为“热点探测”（Hot Spot Code Detection），目前主流的热点探测判定方式有两种，分别是：

  • 基于采样的热点探测（Sample Based Hot Spot Code Detection）：采用这种方法的虚拟机会周期性 地检查各个线程的调用栈顶，如果发现某个（或某些）方法经常出现在栈顶，那这个方法就是“热点方 法”。基于采样的热点探测的好处是实现简单高效，还可以很容易地获取方法调用关系（将调用堆栈展开即可），缺点是很难精确地确认一个方法的热度，容易因为受到线程阻塞或别的外界因素的影响而扰乱热点探测。
  • 基于计数器的热点探测（Counter Based Hot Spot Code Detection）：采用这种方法的虚拟机会为 每个方法（甚至是代码块）建立计数器，统计方法的执行次数，如果执行次数超过一定的阈值就认为 它是“热点方法”。这种统计方法实现起来要麻烦一些，需要为每个方法建立并维护计数器，而且不能直接获取到方法的调用关系。但是它的统计结果相对来说更加精确严谨。

这两种探测手段在商用Java虚拟机中都有使用到，譬如J9用过第一种采样热点探测，而在HotSpot虚拟机中使用的是第二种基于计数器的热点探测方法。为了实现热点计数，HotSpot为每个方法准备了 两类计数器：方法调用计数器（Invocation Counter）和回边计数器（Back Edge Counter，“回边”的意思 就是指在循环边界往回跳转）。当虚拟机运行参数确定的前提下，这两个计数器都有一个明确的阈值，计数器阈值一旦溢出，就会触发即时编译。

方法计数器

对于方法计数器，其用来统计方法被调用的次数，它的 默认阈值在客户端模式下是1500次，在服务端模式下是10000次，这个阈值可以通过虚拟机参数-XX：CompileThreshold来人为设定。并且此时执行流程如下：

当一个方法被调用时，虚拟机会先检查该方法是否存在被即时编译过的 版本，如果存在，则优先使用编译后的本地代码来执行。如果不存在已被编译过的版本，则将该方法 的调用计数器值加一，然后判断方法调用计数器与回边计数器值之和是否超过方法调用计数器的阈值。一旦已超过阈值的话，将会向即时编译器提交一个该方法的代码编译请求。如下图：

方法调用计数器触发即时编译

值得注意的是：在默认设置下，方法调用计数器统计的并不是方法被调用的绝对次数，而是一个相对的执行频 率，即一段时间之内方法被调用的次数。且该值会有一个半衰期，即在一定时间内调用次数仍然不足以让它提交给即时编译器，那么该方法的调用计数器就会被减半。这个时间就是半衰期的具体值。可以使用-XX：UseCounterDecay参数来关闭热度衰减。也可以使用-XX：CounterHalfLifeTime参数来设置半衰期。

回边计数器

关于回边计数器的阈值，虽然HotSpot虚拟机也提供了一个类似于方法调用计数器阈值-XX： CompileThreshold的参数-XX：BackEdgeThreshold供用户设置，但是当前的HotSpot虚拟机实际上并未 使用此参数，我们必须设置另外一个参数-XX：OnStackReplacePercentage来间接调整回边计数器的阈值，其计算公式有如下两种。

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

其流程如下：

回边计数器触发即时编译

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

编译过程

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

在后台执行编译的过程中，服务端编译器和客户端编译器的编译 过程是有所差别的。

对于客户端编译器来说，它是一个相对简单快速的三段式编译器，主要的关注点 在于局部性的优化，而放弃了许多耗时较长的全局优化手段。其过程如下：

  • 第一个阶段，一个平台独立的前端将字节码构造成一种高级中间代码表示（High-Level Intermediate Representation，HIR，即与目标机器指令集无关的中间表示）。HIR使用静态单分配 （Static Single Assignment，SSA）的形式来代表代码值，这可以使得一些在HIR的构造过程之中和之后 进行的优化动作更容易实现。在此之前编译器已经会在字节码上完成一部分基础优化，如方法内联、常量传播等优化将会在字节码被构造成HIR之前完成。
  • 第二个阶段，一个平台相关的后端从HIR中产生低级中间代码表示（Low-Level Intermediate Representation，LIR，即与目标机器指令集相关的中间表示），而在此之前会在HIR上完成另外一些优化，如空值检查消除、范围检查消除等，以便让HIR达到更高效的代码表示形式。
  • 最后的阶段是在平台相关的后端使用线性扫描算法（Linear Scan Register Allocation）在LIR上分配 寄存器，并在LIR上做窥孔（Peephole）优化，然后产生机器代码。

其流程如下图：

![Client Compiler架构](/images/深入理解JVM/Client Compiler架构.jpg)

而服务端编译器则是专门面向服务端的典型应用场景，并为服务端的性能配置针对性调整过的编译器，也是一个能容忍很高优化复杂度的高级编译器，几乎能达到GNU C++编译器使用-O2参数时的 优化强度。

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

提前编译器

所谓提前编译器，就是根据平台的不同，提前将虚拟机代码编译为对应平台的代码。但由于其与Java的一个核心优势-平台中立性的冲突后沉寂下来。但在2013年的Android平台上，提前编译的ART（Android Runtime）的高效性（并且迅速替代了Dalvik编译器）让其又进入大众的视野。

提前编译的优劣得失

现在提前编译产品和对其的研究有着两条明显的分支：

  • 做与传统C、C++编译器类似 的，在程序运行之前把程序代码编译成机器码的静态翻译工作；
  • 把原本即时编译器在运行时要做的编译工作提前做好并保存下来，下次运行到这些代码（譬如公共库代码在被同一台机器其他Java进程使用）时直接把它加载进来使用。

对于第一条，就是传统的提前编译应用形式，它在Java中存在的价值直指即时编译的最大弱点：即时编译要占用程序运行时间和运算资源。即时经过再多的优化，这个事实是不会变化的。

对于第二条，本质是给即时编译器做缓存加速，去改善Java程序的启动时间，以及需要一段时间预热后才能到达最高性能的问题。这种提前编译被称为动态提前编译（Dynamic AOT）或者索性就大大方方地直接叫即时编译缓存（JIT Caching）。在目前的Java技术体系里，这条路径的提前编译已经完全被主流的商用JDK支持。

对于提前编译，不仅需要考虑平台的不同；还需要考虑虚拟机参数的不同等等。所以其实也是一个比较复杂的过程。

还有一个需要思考的问题是：提前编译的代码输出质量，一定会比即时编译更高吗？提前编译在获得时间和资源的优势的同时，也失去了运行时的信息分析能力。

即以下三种即时编译器相对于提前编译器的天然优势：

  • 性能分析制导优化：在运行时，虚拟机可以获取程序运行时的具体信息，如某个程序 点抽象类通常会是什么实际类型、条件判断通常会走哪条分支、方法调用通常会选择哪个版本、循环通常会进行多少次等，这些数据一般在静态分析时是无法得到的，或者不可能存在确定且唯一的解， 最多只能依照一些启发性的条件去进行猜测。
  • 激进预测性优化：这也已经成为很多即时编译优化措施的基础。静态优化无论如何都必须保证优化后所有的程序外部可见影响（不仅仅是执行结果）与优化前是等效的，不然优化之后会导致程序报错或者结果不对，若出现这种情况，则速度再快也是没有价值的。然而，相对于提前编译来说，即时编译的策略就可以不必这样保守，如果性能监控信息 能够支持它做出一些正确的可能性很大但无法保证绝对正确的预测判断，就已经可以大胆地按照高概 率的假设进行优化，万一真的走到罕见分支上，大不了退回到低级编译器甚至解释器上去执行，并不会出现无法挽救的后果。只要出错概率足够低，这样的优化往往能够大幅度降低目标程序的复杂度， 输出运行速度非常高的代码。
  • 链接时优化：Java语言天生就是动态链接的，一个个Class文件在运行期被加载到虚拟机内存当中，然后在即时编译器里产生优化后的本地代码。但对于C、C++等语言，程序要调用某个动态链接库的某个方法，就会出现很明显的边界隔阂，还难以优化。因为主程序与动态链接库的代码在它们编译时是完全独立的，两者各自编译、优化自己的代码。

编译器优化技术

由于编译器优化技术是一种很复杂的技术，包括很多方法，例如，方法内联，逃逸分析等。下面介绍仅仅时编译器优化技术的很小一部分。

优化技术概览

OpenJDK的官方Wiki上，HotSpot虚拟机设计团队列出了一个相对比较全面的、即时编译器中采用的优化技术列表。其中有不少经典编译器的优化手段，也有许多针对Java语言，或 者说针对运行在Java虚拟机上的所有语言进行的优化。在后面，我们挑选几种最经典或重要的优化作为分析。

即时编译器优化技术一览1

即时编译器优化技术一览2

上述的优化技术看起来很多，而且名字看起来大多显得有点“高深莫测”，实际上要实现这些优化 确实有不小的难度，但大部分优化技术理解起来都并不困难。

方法内联

方法内联式编译器优化的最重要手段，甚至都可以不加 上“之一”。

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

如下代码：例子里testInline()方法的内部全部是无用的代码，但如 果不做内联，后续即使进行了无用代码消除的优化，也无法发现任何“Dead Code”的存在。如果分开来看，foo()和testInline()两个方法里面的操作都有可能是有意义的。

1
2
3
4
5
6
7
8
9
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);
}

方法内联的优化行为理解起来是没有任何困难的，不过就是把目标方法的代码原封不动地“复 制”到发起调用的方法之中，避免发生真实的方法调用而已。但实际上Java虚拟机中的内联过程却远没 有想象中容易，甚至如果不是即时编译器做了一些特殊的努力，按照经典编译原理的优化理论，大多数的Java方法都无法进行内联。

无法内联的原因其实在于Java方法分配的原理：只有使用 invokespecial指令调用的私有方法、实例构造器、父类方法和使用invokestatic指令调用的静态方法才会在编译期进行解析。除了上述四种方法之外（最多再除去被final修饰的方法这种特殊情况，尽管它使 用invokevirtual指令调用，但也是非虚方法，《Java语言规范》中明确说明了这点），其他的Java方法调用都必须在运行时进行方法接收者的多态选择，它们都有可能存在多于一个版本的方法接收者，简而言之，Java语言中默认的实例方法是虚方法。

对于一个虚方法，编译器静态地去做内联的时候很难确定应该使用哪个方法版本。

糟糕的情况是，由于Java提倡使用面向对象的方式进行编程，而Java对象的方法默认就是虚方 法，可以说Java间接鼓励了程序员使用大量的虚方法来实现程序逻辑。

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

这样，编译器在进行内联时就会分不同情况采取不同的处理：

  • 如果是非虚方法，那么直接进 行内联就可以了，这种的内联是有百分百安全保障的。
  • 如果遇到虚方法，则会向CHA查询此方法在当前程序状态下是否真的有多个目标版本可供选择。
    • 如果查询到只有一个版本，那就可以假设“应用程序 的全貌就是现在运行的这个样子”来进行内联，这种内联被称为守护内联（Guarded Inlining）。不过由 于Java程序是动态连接的，说不准什么时候就会加载到新的类型从而改变CHA结论，因此这种内联属 于激进预测性优化，必须预留好“逃生门”，即当假设条件不成立时的“退路”（Slow Path）。假如在程 序的后续执行过程中，虚拟机一直没有加载到会令这个方法的接收者的继承关系发生变化的类，那这 个内联优化的代码就可以一直使用下去。如果加载了导致继承关系发生变化的新类，那么就必须抛弃已经编译的代码，退回到解释状态进行执行，或者重新进行编译。
    • 如果查询到的结果是该方法确实有多个版本的目标方法可供选择，那即时编译器还将进行最后一次努力，使用内联缓存（Inline Cache）的方式来缩减方法调用的开销。这种状态下方法调用是真正发生了的，但是比起直接查虚方法表还是要快一些。内联缓存是一个建立在目标方法正常入口 之前的缓存，它的工作原理大致为：在未发生方法调用之前，内联缓存状态为空，当第一次调用发生 后，缓存记录下方法接收者的版本信息，并且每次进行方法调用时都比较接收者的版本。如果以后进 来的每次调用的方法接收者版本都是一样的，那么这时它就是一种单态内联缓存（Monomorphic Inline Cache）。通过该缓存来调用，比用不内联的非虚方法调用，仅多了一次类型判断的开销而已。但如果真的出现方法接收者不一致的情况，就说明程序用到了虚方法的多态特性，这时候会退化成超多态内联缓存（Megamorphic Inline Cache），其开销相当于真正查找虚方法表来进行方法分派。

所以说，在多数情况下Java虚拟机进行的方法内联都是一种激进优化。事实上，激进优化的应用在高性能的Java虚拟机中比比皆是，极为常见。除了方法内联之外，对于出现概率很小（通过经验数 据或解释器收集到的性能监控信息确定概率大小）的隐式异常、使用概率很小的分支等都可以被激进优化“移除”，如果真的出现了小概率事件，这时才会从“逃生门”回到解释状态重新执行。

逃逸分析

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

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

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

  • 栈上分配：在Java虚拟机中，Java堆上分配创建对象的内存空间几乎是 Java程序员都知道的常识，Java堆中的对象对于各个线程都是共享和可见的，只要持有这个对象的引用，就可以访问到堆中存储的对象数据。虚拟机的垃圾收集子系统会回收堆中不再使用的对象，但回 收动作无论是标记筛选出可回收对象，还是回收和整理内存，都需要耗费大量资源。如果确定一个对象不会逃逸出线程之外，那让这个对象在栈上分配内存将会是一个很不错的主意，对象所占用的内存空间就可以随栈帧出栈而销毁。在一般应用中，完全不会逃逸的局部对象和不会逃逸出线程的对象所占的比例是很大的，如果能使用栈上分配，那大量的对象就会随着方法的结束而自动销毁了，垃圾收集子系统的压力将会下降很多。栈上分配可以支持方法逃逸，但不能支持线程逃逸。
  • 标量替换：若一个数据已经无法再分解成更小的数据来表示了，Java虚拟 机中的原始数据类型（int、long等数值类型及reference类型等）都不能再进一步分解了，那么这些数据就可以被称为标量。相对的，如果一个数据可以继续分解，那它就被称为聚合量（Aggregate），Java 中的对象就是典型的聚合量。如果把一个Java对象拆散，根据程序访问的情况，将其用到的成员变量恢复为原始类型来访问，这个过程就称为标量替换。假如逃逸分析能够证明一个对象不会被方法外部 访问，并且这个对象可以被拆散，那么程序真正执行的时候将可能不去创建这个对象，而改为直接创
    建它的若干个被这个方法使用的成员变量来代替。将对象拆分后，除了可以让对象的成员变量在栈上 （栈上存储的数据，很大机会被虚拟机分配至物理机器的高速寄存器中存储）分配和读写之外，还可以为后续进一步的优化手段创建条件。标量替换可以视作栈上分配的一种特例，实现更简单（不用考虑整个对象完整结构的分配），但对逃逸程度的要求更高，它不允许对象逃逸出方法范围内。
  • 同步消除：线程同步本身是一个相对耗时的过程，如果逃逸分析 能够确定一个变量不会逃逸出线程，无法被其他线程访问，那么这个变量的读写肯定就不会有竞争，对这个变量实施的同步措施也就可以安全地消除掉。

例如：

原始代码：

1
2
3
4
// 完全未优化的代码 
public int test(int x) { 
    int xx = x + 2; Point p = new Point(xx, 42); return p.getX();
}

第一步：将Point的构造函数和getX()方法进行内联优化：

1
2
3
4
5
6
7
8
// 步骤1：构造函数内联后的样子 
public int test(int x) { 
    int xx = x + 2; 
    Point p = point_memory_alloc();
	p.x = xx;
	p.y = 42;
    return p.x;
}

第二部：经过逃逸分析，发现在整个test()方法的范围内Point对象实例不会发生任何程度的逃逸， 这样可以对它进行标量替换优化，把其内部的x和y直接置换出来，分解为test()方法内的局部变量，从而避免Point对象实例被实际创建，优化后的结果如下所示：

1
2
3
4
5
6
7
// 步骤2：标量替换后的样子 
public int test(int x) { 
    int xx = x + 2; 
    int px = xx; 
    int py = 42; 
    return px;
}

第三步，通过数据流分析，发现py的值其实对方法不会造成任何影响，那就可以放心地去做无效 代码消除得到最终优化结果，如下所示：

1
2
3
4
// 步骤3：做无效代码消除后的样子 
public int test(int x) { 
    return x + 2;
}

公共子表达式消除

公共子表达式消除是一项非常经典的、普遍应用于各种编译器的优化技术，它的含义是：如果一 个表达式E之前已经被计算过了，并且从先前的计算到现在E中所有变量的值都没有发生变化，那么E的这次出现就称为公共子表达式。

对于这种表达式，没有必要花时间再对它重新进行计算，只需要直 接用前面计算过的表达式结果代替E。

如果这种优化仅限于程序基本块内，便可称为局部公共子表达 式消除（Local Common Subexpression Elimination），如果这种优化的范围涵盖了多个基本块，那就称为全局公共子表达式消除（Global Common Subexpression Elimination）。例如：

1
int d = (c * b) * 12 + a + (a + b * c);

当这段代码进入虚拟机即时编译器后，它将进行如下优化：编译器检测到c*b与b*c是一样的表达 式，而且在计算期间b与c的值是不变的。因此其可能被优化为：

1
int d = E * 12 + a + (a + E);

这时候，编译器还可能（取决于哪种虚拟机的编译器以及具体的上下文而定）进行另外一种优化 ——代数化简（Algebraic Simplification），在E本来就有乘法运算的前提下，把表达式变为：

1
int d = E * 13 + a + a;

表达式进行变换之后，再计算起来就可以节省一些时间了。

数组边界检查消除

数组边界检查消除（Array Bounds Checking Elimination）是即时编译器中的一项语言相关的经典优化技术。我们知道Java语言是一门动态安全的语言，对数组的读写访问也不像C、C++那样实质上就是裸指针操作。但实际上虚拟机就必须在每次访问的时候去检测下标是否超过了范围，这也是一种性能消耗。

为了消除这些隐式开销，除了如数组 边界检查优化这种尽可能把运行期检查提前到编译期完成的思路之外，还有一种避开的处理思路—— 隐式异常处理，Java中空指针检查和算术运算中除数为零的检查都采用了这种方案。举个例子，程序 中访问一个对象（假设对象叫foo）的某个属性（假设属性叫value），那以Java伪代码来表示虚拟机访
问foo.value的过程为：

1
2
3
4
5
if (foo != null) { 
    return foo.value;
}else{ 
    throw new NullPointException();
}

在使用隐式异常优化之后，虚拟机会把上面的伪代码所表示的访问过程变为如下伪代码：

1
2
3
4
5
try { 
    return foo.value;
} catch (segment_fault) { 
    uncommon_trap();
}

虚拟机会注册一个Segment Fault信号的异常处理器（伪代码中的uncommon_trap()，务必注意这里 是指进程层面的异常处理器，并非真的Java的try-catch语句的异常处理器），这样当foo不为空的时 候，对value的访问是不会有任何额外对foo判空的开销的，而代价就是当foo真的为空时，必须转到异 常处理器中恢复中断并抛出NullPointException异常。进入异常处理器的过程涉及进程从用户态转到内 核态中处理的过程，结束后会再回到用户态，速度远比一次判空检查要慢得多。当foo极少为空的时 候，隐式异常优化是值得的，但假如foo经常为空，这样的优化反而会让程序更慢。幸好HotSpot虚拟机足够聪明，它会根据运行期收集到的性能监控信息自动选择最合适的方案。

Powered by Hexo and Hexo-theme-hiker

Copyright © 2019 - 2024 My Wonderland All Rights Reserved.

UV : | PV :