深入理解Java虚拟机（周志明第三版）- 第十一章：后端编译与优化_深入理解java虚拟机周志明实战

系列文章目录

第一章： 走近Java
第二章： Java内存区域与内存溢出异常
第三章： Java垃圾收集器与内存分配策略

---

一、概述

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

无论是提前编译器或即时编译器，都不是Java虚拟机必须的组成部分，《Java虚拟机规范》并没有规定过虚拟机内部必须要包含这些编译器，更没有限定或指导这些编译器如何去实现，但是，后端编译器编译性能的好坏、优化代码质量的高低却是衡量一款商用虚拟机优秀与否的关键指标之一，它们也是商业Java虚拟机中的核心，是最能体现技术水平与价值的功能。

---

二、即时编译器

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

1、解释器与编译器

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

1.2 为何Hotspot虚拟机要实现两个或三个不同的即时编译器？
答：Hotspot虚拟机中内置了两个（或三个）即时编译器：客户端编译器（简称C1）、服务端编译器（简称C2）、Graal编译器（JDK10时才出现的，长期目标是替代C2编译器，目前处于实验状态）。
        在分层编译的工作模式出现前，Hotspot通常是采用解释器与其中一个编译器直接配合使用的方式工作，程序使用那个编译器，只取决于虚拟机运行的模式，Hotspot虚拟机会根据自身版本与宿主机器的硬件性能自主选择运行模式，也可以使用<-client>或<-server>强制指定虚拟机运行模式。无论采用的编译器是客户端还是服务端，这种搭配使用的方式称为”混合模式（Mix Mode）“，也可以使用参数”-Xint“强制运行于”解释器模式“，这时编译器不介入工作，全部代码采用解释方式执行，也可以使用参数”-Xcomp“强制运行于”编译模式“，这时优先采用编译方式执行程序，但是解释器仍然会在编译器无法进行的情况下介入执行过程。可以通过”-version“来输出

1.3 什么是分层编译？
     由于即时编译器编译本地代码需要占用程序运行时间，通常要编译出优化程度越高的代码，所花费的时间就越长；而且想要编译出优化程度高的代码，解释器可能还要替编译器收集性能监控信息，这对解释执行阶段也有所影响。为了在程序启动响应速度与运行效率之间达到最佳平衡，Hotspot虚拟机在编译子系统中加入了分层编译的功能（JDK7的服务端模式作为默认编译策略被开启），根据编译器编译、优化的规模与耗时，划分出不同的编译层次：
     -第0层：程序纯解释器执行，并且不开启性能监功能
     -第1层：使用客户端编译器将字节码编译为本地代码来运行，进行简单可靠的稳定优化，不开启性能监控功能
     -第2层：仍然使用客户端编译器执行，仅开启方法及回边统计等有限的性能监控功能
     -第3层：仍然使用客户端编译器执行，开启全部性能监控，除了第2层的统计信息外，还会收集如分支跳转、虚方法调用版本等全部的统计信息
     -第4层：使用服务端编译将字节码编译为本地代码，相比客户端编译器，服务端编译器会启用更多编译耗时长的优化，还会根据性能监控信息进行一些不可靠的激进优化

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

2、编译对象与触发条件

哪些程序代码会被编译为本地代码？
答：在运行过程中被即时编译器的目标是”热点代码“，主要有两类：

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

      对于这两种情况，编译的目标都是整个方法体，而不会是单独的循环体。第一种情况由于是依靠方法调用触发的编译，那编译器理所当然会以整个方法作为编译对象，这种编译也是虚拟机中标准的即时编译方式。而对于第二种情况，尽管编译动作是由循环体触发的，热点只是方法的一部分，但编译器依赖必须以整个方法为编译对象，只是执行入口（从方法第几条字节码指令开始执行）会有所不同，编译时会传入执行入口点字节码序号。这种编译方式因为编译发生在方法执行过程中，因此也被称为“栈上替换”，即方法的栈帧还在栈上，方法就被替换了。

;判断某段代码是不是热点代码，是不是需要触发即时编译，这个行为称为“热点探测”。目前主流的热点探测方式有两种：

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

      OpenJ9虚拟机采用第一种采样热点探测，而Hotspot虚拟机使用的是第二种基于计数器统计的热点探测。为了实现热点计数，Hotspot为每个方法准备了两类计数器：方法计数器和回边计数器（指在循环边界往回跳转）。当虚拟机运行参数确定的前提下，这两个计数器都有一个明确的阈值，计数器阈值超出，就会触发即时编译。

方法计数器：统计方法调用的次数。默认阈值在看客户端模式下是1500，在服务端模式下是10000次，通过虚拟机参数-XX:CompileThreshold来人为设定。当一个方法被调用时，虚拟机先会检查该方法是否存在被编译过的版本，如果存在，则优先使用编译后的本地代码来执行，如果不存在已被编译过的版本则将该方法的调用次数加1，然后判断该方法调用计数器与回边计数器之和是否超过方法调用计数器的阈值，一旦超过阈值，将会向即时编译器提交一个方法的代码编译请求。执行引擎默认不会同步等待编译请求完成，二是继续进入解释器按照解释方式执行字节码，直到提交的请求被即时编译器编译完成，当编译完成后，这个方法的调用入口地址就会被系统自动改写成新值，下一次调用该方法就会使用已编译的版本。
  
热度衰减：默认设置下方法计数器统计的并不是方法调用的绝对次数，而是一个相对的执行频率，即一段时间内方法被调用的次数。当超过一定的时间限度，如果方法的调用次数仍然不足以让他提交给即时编译器编译，那该方法的调用计数器就会减少一半，这个过程称为方法调用计数器热度的衰减。而这段时间称为此方法统计的半衰周期。进行热度衰减的动作是在虚拟机进行垃圾收集时顺便进行的，可以使用虚拟机参数-XX：- UseCounterDecay来关闭热度衰减，让方法计数器统计方法调用的绝对次数，这样只要系统运行时间足够长，程序中绝大部分方法都会被编译成本地代码。另外还可以使用-XX：CounterHalfLifeTime参数设置半衰周期的时间，单位是秒。

回边计数器：统计一个方法中循环体代码执行的次数，在字节码中遇到控制流向后跳转的指令就称为“回边”。当解释器遇到一条回边指令时，会先查找将要执行的代码片段是否有已经编译好的版本，如果有就优先执行编译版本，否则就把回边计数器的值加1.，然后判断回边计数器与方法调用计数器之和是否超过回边计数器的阈值。当超过时会向编译器提交一个栈上替换编译请求，并且把回边计数器的值略微降低一些，以便在解释器中执行循环，等待编译器输出编译结果。
  
回边计数器没有计数热度衰减的过程，因此统计的是该方法循环执行的绝对次数。当计数器溢出的时候，它还会把方法计数器的值也调整到溢出状态，这样下次再进入该方法时候就会执行标准编译过程

！！！上述两张即时编译图仅仅描述的是客户端虚拟机的即时编译方式，对于服务端模式虚拟机来说，执行情况会比上面描述还要复杂一些。

3、编译过程

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

第一个阶段，一个平台独立的前端将字节码构造成一种高级中间代码表示（High-Level Intermediate Representation，HIR，即与目标机器指令集无关的中间表示），HIR使用静态单分派的形式来代表代码值，这可以使得一些再HIR的构造过程之中和之后进行的优化动作更容易实现。在此之前编译器已经会在字节码上完成一部分基础优化，如方法内联、常量传播等优化方式会在字节码被构造成HIR之前完成。

第二个阶段，一个平台相关的后端从HIR中产生低级中间代码表示（Low-Level Intermediate Representation，LIR，即与目标机器指令集相关的中间表示），而在此之前会在HIR上完成另外一些优化，如空值检查消除、范围检查消除等，以便让HIR达到更高效的代码表示形式。

第三个阶段，在平台相关的后端使用线性扫描算法在LIR上分配寄存器，并在LIR上做窥孔优化，然后产生机器码。

服务端编译器编译过程：
    服务端编译器是专门面向服务端的典型应用场景，并为服务端的性能配置针对性调整过的编译器，也是一个能容忍很高复杂度的高级编译器，它会执行大部分经典的优化动作，如：无用代码消除、循环展开、循环表达式外提、消除公共子表达式、常量传播、基本块重排序等，还会实施一些与Java语言特性密切相关的优化技术，如范围检查消除、空值检查消除等，另外，还会根据解释器或客户端编译器提供的性能监控信息进行一些不稳定的预测性激进优化，如守护内联、分支频率预测等。
    服务端采用的寄存器分配器是一个全局图着色分配器，它可以充分利用某些处理器架构上大寄存集合，以即时编译器的标准看，服务端编译器是比较缓慢的，但它的编译速度依然远远超过传统的静态优化编译器，而且它相对于客户端编译器输出的代码质量有很大提高，可以大幅减少本地代码的执行时间，从而抵消掉额外的编译时间开销。

4、实战：查看及分析即时编译结果

如何从外部观察到即时编译器的编译过程和编译结果？

---

三、提前编译器

1、提前编译器的优劣得失

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

即时编译要占用程序运行时间和运算资源，因为无论如何优化，即时编译消耗的时间都是原本可用于程序运行的时间，消耗的资源都是原本程序运行的资源，这个约束从未减弱，更不会消失。
提前编译器因为没有执行时间和资源限制的压力，可以毫无限制地使用重负载的优化手段。

即时编译器对比提前编译器的三种优势：

• 性能分析制导优化：即时编译器可以根据解释器或客户端编译器运行过程中收集的性能监控信息去做一些分析优化（如某个程序点抽象类通常会是什么实际类型、条件判断通常会走哪条分支、方法调用通常会选择哪个版本、循环通常会进行多少次等，这些数据一般在静态分析时是无法得到的，或者不存在确定且唯一的解，但在动态运行时却能看出它们具有非常明显的偏好性，如果一个条件分支的某一条路经执行特别频繁，而其他路径鲜有问津，那就可以把热的代码集中放到一起，集中优化和分配更好的资源给它）
• 激进预测性优化：静态优化无论如何都必须保证优化后所有的程序外部可见影响与优化前是等效的，不能出现优化后程序报错或结果不对，且没有所谓的逃生门，而即时编译可以基于性能监控信息等进行大胆预测，万一真走到罕见分支上，大不了退回到低级编译器或解释器执行，并不会出现无法挽救的结果。
• 链接时优化：Java语言天生就是动态链接的，一个个Class文件在运行期间被加载到虚拟机内存中，然后在编译器里产生优化后的本地代码。而譬如C、C++的程序要调用某个动态链接库的某个方法，就会出现明显的隔阂，还难以优化，因为主程序与动态链接库的代码在编译时是完全独立的，两者各自编译、优化自己的代码。

2、实战：Jaotc的提前编译

Ahead-of-Time Compilation

---

四、编译器优化技术

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

1、优化技术概览

为了方便讲解，使用了Java语言的语法来表示这些优化技术所发挥的作用

原始代码：
public class A {

    static class B {
        int value;

        final int get() {
            return value;
        }
    }

    public void foo() {
        B b = new B();
        int y = b.get();
        // ...do stuff...
        int z = b.get();
        int sum = y + z;
    }
}


第一步优化：方法内联（主要目的有两个：一是去除方法调用的成本（查找方法版本、建立栈帧等）；二是为其他优化建立良好的基础）
public void foo() {
    B b = new B();
    int y = b.value;
    // ...do stuff...
    int z = b.value;
    int sum = y + z;
}

第二步：冗余访问消除（假设代码中注释的内容不会改变b.value的值，那么就可以把z=b.value替换为z=y，避免再去访问对象b中的局部变量）
public void foo() {
    B b = new B();
    int y = b.value;
    // ...do stuff...
    int z = y;
    int sum = y + z;
}

第三步：复写传播（这段程序逻辑中没有必要使用一个额外的变量z，它与变量y是完全相等的，因此我们可以使用y代替z）
public void foo() {
    B b = new B();
    int y = b.value;
    // ...do stuff...
    int y = y;
    int sum = y + y;
}

第四步：无用代码消除（无用代码可能是永远不会被执行的代码，也可能是完全没意义的代码）
public void foo() {
    B b = new B();
    int y = b.value;
    // ...do stuff...
    int sum = y + y;
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

2、方法内联（最重要的优化技术之一）

方法内联的优化行为理解起来就是把目标方法的代码原封不动“复制”到发起调用的方法中，避免发生真实的方法调用。

但实际上Java虚拟机的方法内联远远没有这么容易。由于Java语言中默认的实例方法是虚方法，对于一个虚方法，编译器静态地去做内联时很难决定应该使用哪个方法版本。

为了解决虚方法的内联问题，Java虚拟机引入了一种类型继承关系分析（Class Hierarchy Analysis，CHA）的技术，这是整个应用范围内的类型分析技术，用于确定在目前已加载的类中，某个接口是否有多于一种的实现、某个类是否存在子类、某个子类是否覆盖了父类的某个虚方法等信息，这样编译器在进行内联时就会根据不同情况采取不同处理：

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

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

3、逃逸分析（最前沿的优化技术之一）

逃逸分析与类型继承关系分析一样，并不是直接优化代码的手段，而是为其他优化措施提供依据的分析技术。

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

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

• 栈上分配（由于复杂度等原因，Hotspot虚拟机暂时没有这项优化）

在Java虚拟机中，分配创建对象的内存空间是在堆上，堆中的对象对于各个线程都是共享和可见的，只要持有这个对象的引用，就可以访问到堆中存储的对象数据。虚拟机的垃圾收集子系统会回收堆中不再使用的对象，但回收动作无论是标记筛选出可回收对象，还是回收整理内存，都需要耗费大量资源。如果确定一个对象不会逃逸出线程之外，可以让这个对象在栈上分配内存，对象所占用的内存空间就会随栈帧出栈而销毁。在一般应用中，完全不会逃逸的局部对象和不会逃逸出线程的对象所占比例是很大的，如果栈上分配这样实现，大量的对象就会随着方法的结束而自动销毁，垃圾收集子系统的压力将会下降许多。栈上分配可以支持方法逃逸，但不能支持线程逃逸。

• 标量替换

若一个数据已经无法再分解成更小的数据来表示了，Java虚拟机中的原始数据类型（int、long等数值类型及reference类型）等都不能再进一步分解了，那么这些数据就可以被称为“标量”，相对地，如果一个数据可以继续分解，那它就被称为聚合量，Java中的对象就是典型的聚合量。如果把一个Java对象拆散，根据程序访问的情况，将其用到的成员变量恢复为原始类型来访问，这个过程就成为标量替换。假如逃逸分析能够证明一个对象不会被方法外部访问到，并且这个对象可以被拆散，那么程序真正执行的时候将可能不去创建这个对象，而改为直接创建它的若干个被这个方法使用的成员变量来代替。将对象拆分后，除了可以让对象的成员变量在栈上分配和读写之外，还可以为后续进一步的优化手段创建条件。标量替换可以作为栈上分配的一种特例。实现更简单（不用考虑整个对象完整结构的分配），但对逃逸程度的要求更高，它不允许对象逃逸出方法范围内。

• 同步消除

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

  
通过Java伪代码的变换过程模拟逃逸分析是如何工作的

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

第一步：将Point的构造函数和getX()方法内联优化
// 步骤1：构造函数内联后的样子
public int test(int x) { 
	int xx = x + 2;
	Point p = point_memory_alloc();	// 在堆中分配P对象的示意方法
	p.x = xx;	// Point构造函数被内联后的样子
	p.y = 42
	return p.x;	// Point::getX()被内联后的样子
}

第二步：经过逃逸分析，发现在整个test方法内Point对象实例不会发生任何程度的逃逸，可以进行标量替换优化，避免Point对象实例被实际创建
// 步骤2：标量替换后的样子
public int test(int x) { 
	int xx = x + 2;
	int px = xx; 
	int py = 42;
	return px;
}

第三步：通过数据流分析，发现变量py的值不会对结果发生任何影响，可以进行无用代码消除优化
// 步骤3：做无效代码消除后的样子
public int test(int x) { 
	return x + 2;
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

JDK7版本时逃逸分析这项优化才成为服务端编译器默认开启的选项。
-XX：+DoEscapeAnalysis来手动开启逃逸分析。
-XX：+PrintEscapeAnalysis来查看分析结果。
-XX：+EliminateAllocations来开启标量替换，
+XX：+EliminateLocks来开启同步消除
-XX：+PrintEliminateAllocations查看标量的替换情况。

4、公共子表达式消除（语言无关的经典优化技术之一）

含义：如果一个表达式E之前已经被计算过了，并且从先前的计算机现在E中所有变量的值都没有发生变化，那么E的这次出现就称为公共子表达式，对于这种表达式，没必要重新计算，只需要直接用前面计算过的表达式结果代替E。如果这种优化仅限于程序基本块内，便可称为局部公共子表达式消除，如果这种优化的范围涵盖了多个基本块，那就称为全局公共子表达式消除。

示例：

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


即时编译器检测到c*b 与b*c是一样的表达式且计算期间两变量值是不变的，因此这条表达式可能被视为
int d = E * 12 + a + (a + E);

这时候编译器还可能（取决于哪种虚拟机的编译器及具体的上下文而定）进行另外一种优化----代数化简
int d = E * 13 + a + a;

1
2
3
4
5
6
7
8
9

5、数组边界检查消除（语言相关的经典优化技术之一）

Java语言是一门动态安全的语言，对数组的读写访问不用像C、C++那样裸指针操作，如果有一个数组foo[]，在Java语言中访问数组元素foo[i]时系统会自动进行上下界的范围检查，即必须满足i>=0&&i<foo.length的访问条件，否则将抛出数组越界异常 java.lang.ArrayIndexOutOfBoundsException，这对软件开发者是很友好的一件事，即时程序员没有专门编写防御代码，也能够避免大多数的溢出攻击。但是对于虚拟机的执行子系统来说，每次读写数组元素都带有一次隐含的条件判断操作，对于拥有大量数组访问的程序代码，这必定是一种性能负担。

为了安全，数组边界检查肯定是要做的，但数组边界检查是不是必须在运行期间一次不漏地进行则是可以“商量”的事情，例：数组下标是一个常量，foo[3]，只要在编译期根据数据流分析来确定foo的length的值，并判断下标3没有越界，执行的时候就无需判断了。更常见的情况是，数组访问发生在循环内，并且使用循环变量来进行数组的访问。如果编译器只要通过数据流分析就可以判定循环变量的取值范围永远在区间内，那么在循环中就可以把整个数组的边界检查消除掉，这样可以节省很多次的条件判断操作。

除了数组边界检查之外，空指针异常、算法异常等等类似，大量的安全检查使编写Java程序对比C、C++更容易，但这些安全检查也带来了一些隐式开销。为了消除这些隐式开销，除了如数组边界检查优化这种尽可能把运行期检查提前到编译期完成之外，还有一种避开的处理思路—隐式异常处理器，Java中空指针异常和算数运算异常都采用了这种方案。

例：Java伪代码模拟
if (foo != null) { 
	return foo.value;
}else{
	throw new NullPointException();
}

在使用隐式异常优化后，虚拟机会把上面的伪代码优化为
try {
	return foo.value;
} catch (segment_fault) { 
	uncommon_trap();
}
1
2
3
4
5
6
7
8
9
10
11
12
13

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

---

五、实战：深入理解Graal编译器

Graal编译器在JDK 9时以Jaotc提前编译工具的形式首次加入到官方的JDK中，从JDK 10起，Graal 编译器可以替换服务端编译器，成为HotSpot分层编译中最顶层的即时编译器。这种可替换的即时编译器架构的实现，得益于HotSpot编译器接口的出现。

早期的Graal曾经同C1及C2一样，与HotSpot的协作是紧耦合的，这意味着每次编译Graal均需重新编译整个HotSpot。JDK 9时发布的JEP 243：Java虚拟机编译器接口（Java-Level JVM Compiler Interface，JVMCI）使得Graal可以从HotSpot的代码中分离出来。JVMCI主要提供如下三种功能：

• ·响应HotSpot的编译请求，并将该请求分发给Java实现的即时编译器
• 允许编译器访问HotSpot中与即时编译相关的数据结构，包括类、字段、方法及其性能监控数据等，并提供了一组这些数据结构在Java语言层面的抽象表示
• ·提供HotSpot代码缓存（Code Cache）的Java端抽象表示，允许编译器部署编译完成的二进制机器
  码

综合利用上述三项功能，我们就可以把一个在HotSpot虚拟机外部的、用Java语言实现的即时编译器（不局限于Graal）集成到HotSpot中，响应HotSpot发出的最顶层的编译请求，并将编译后的二进制代码部署到HotSpot的代码缓存中。此外，单独使用上述第三项功能，又可以绕开HotSpot的即时编译系统，让该编译器直接为应用的类库编译出二进制机器码，将该编译器当作一个提前编译器去使用

---

六、附录

JVM系列之：宏观分析Java代码是如何执行的
Java即时编译器原理解析及实践
Graal编译器