You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
72 lines
6.2 KiB
72 lines
6.2 KiB
---
|
|
晚期（运行期）优化
|
|
---
|
|
|
|
### 目录
|
|
|
|
1. 概述
|
|
2. HotSpot 虚拟机内的即时编译器
|
|
|
|
### 概述
|
|
|
|
在部分的商用虚拟机（HotSpot），Java 程序最初是通过解释器进行解释执行的，当虚拟机发现某个方法或代码块的运行特别频繁时，就会把这些代码认定为 “热点代码”。为了提高热点代码的执行效率，在运行时，虚拟机将会把这些代码编译成与本地平台相关的机器码，并进行各种层次的优化，完成这个任务的编译器就称为即时编译器，即 JIT 编译器。
|
|
|
|
### HotSpot 虚拟机内的即时编译器
|
|
|
|
先来思考以下几个问题：
|
|
|
|
1. 为何 HotSpot 虚拟机要使用解释器和编译器并存的架构？
|
|
2. 为何 HotSpot 虚拟机要实现两个不同的即时编译器？
|
|
3. 程序何时使用解释器执行？何时使用编译器执行？
|
|
4. 哪些程序代码会被编译为本地代码？如果编译为本地代码？
|
|
5. 如何从外部观察即时编译器的编译过程和编译结果？
|
|
|
|
#### 解释器与编译器
|
|
|
|
尽管并不是所有的 Java 虚拟机都采用解释器与编译器并存的架构，但很多主流的商用虚拟机，如 HotSpot、J9等，都同时包含解释器与编译器。解释器与编译器两者各有优劣：当程序需要迅速启动和执行的时候，解释器可以首先发挥作用，省去编译的时间，立即执行。在程序运行后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码之后，可以获取更高的执行效率。当程序运行环境中内存资源限制较大，可以使用解释执行节约内存，反之可以使用编译执行来提高效率。同时，解释器还可以作为编译器激进优化时的一个 “逃生门”，让编译器根据概率选择一些大多数时候都能提升运行速度的优化手段，当激进优化的假设不成立，如加载了新类后类型继承结构出现变化、出现 “罕见陷阱” 时可以通过逆优化退回到解释状态继续执行。
|
|
|
|
HotSpot 虚拟机中内置了两个即时编译器，分别称为 Client Compiler 和 Server Compiler，或者简称为 C1 编译器和 C2 编译器。用户可以配置虚拟机参数强制虚拟机运行于解释模式或者编译模式。
|
|
|
|
由于即时编译器编译本地代码需要占用程序运行时间，要编译出优化程度更高的代码，所发费的时间可能更长；而且想要编译出优化程度更高的代码，解释器可能还要替换编译器收集性能监控信息，这对解释执行的速度也有影响。为了在程序启动响应速度与运行效率之间达到最佳平衡，HotSpot 虚拟机还会逐渐启用分层编译的策略。分层编译根据编译器编译、优化的规模与耗时，划分出不同的编译层次，其中包括：
|
|
|
|
* 第 0 层
|
|
|
|
程序解释执行，解释器不开启性能监控功能（Profiling），可触发第 1 层编译。
|
|
|
|
* 第 1 层
|
|
|
|
也称为 C1 编译，将字节码编译为本地代码，进行简单、可靠的优化，如有必要将加入性能监控的逻辑。
|
|
|
|
* 第 2 层
|
|
|
|
也是将字节码编译为本地代码，但是会启用一些编译耗时较长的优化，甚至会根据性能监控信息进行一些不可靠的激进优化。
|
|
|
|
实施分层编译后，Client Compiler 和 Server Compiler 将会同时工作，很多代码都可能会被多次编译，用 Client Compiler 获取更高的编译速度，用 Server Compiler 来获取更好地编译质量，在解释执行的时候也无需再承担收集性能监控信息的任务。
|
|
|
|
#### 编译对象与触发条件
|
|
|
|
上文中提到过，在运行过程中会被即时编译器编译的 “热点代码” 有两类，即：
|
|
|
|
* 被多次调用的方法
|
|
* 被多次执行的循环体
|
|
|
|
前者很好理解，一个方法被调用的多了，方法体内代码执行的次数自然就多，它成为 “热点代码” 是理所当然的。而后者则是为了解决一个方法只被调用过一次或少量的几次，但是方法体内部都存在循环次数较多的循环体的问题，这样循环体的代码也被重复执行多次，因此这些代码也应该认为是 “热点代码”。
|
|
|
|
对于第一种情况，由于是由方法调用触发的编译，因此编译器理所当然的会以整个方法作为编译对象，这种编译也是虚拟机中标准的 JIT 编译方式。而对于后一种情况，尽管编译动作是由循环体所触发的，但编译器依然会以整个方法（而不是单独的循环体）作为编译对象。这种编译方式因为编译发生在方法执行过程之中，因此形象的称之为栈上替换（OSR ）。
|
|
|
|
那多少次才算 “多次” 呢？虚拟机如何统计一个方法或一段代码被执行多少次了呢？解决这两个问题，也就回答了即时编译被触发的条件。
|
|
|
|
判断一段代码是不是热点代码，是不是需要触发即时编译，这样的行为称为热点探测，其实进行热点探测并不一定要知道方法具体被调用了多少次，目前主要的热点探测判定方式有两种，分别如下：
|
|
|
|
* 基于采样的热点探测
|
|
|
|
采用这种方法的虚拟机会周期性的检查各个线程的栈顶，如果发现某个方法经常出现在栈顶，那么这个方法就是 “热点方法”。基于采样的热点探测的好处是实现简单、高效，还可以很容易的获取方法调用关系，缺点是很难精确地确认一个方法的热度，容易因为受到线程阻塞或别的外界因素的影响而扰乱热点探测。
|
|
|
|
* 基于计数器的热点探测
|
|
|
|
采用这种方法的虚拟机会为每个方法（甚至是代码块）建立计数器，统计方法的执行次数，如果执行次数超过一定的阈值就认为它是 “热点方法”。这种统计方法实现起来要麻烦一些，需要为每个方法建立并维护计数器，而且不能直接获取到方法的调用关系，但是它的统计结果相对来说更加精确和严谨。
|
|
|
|
在 HotSpot 虚拟机中使用的是第二种 --- 基于计数器的热点探测方法，因此它为每个方法准备了两类计数器：方法调用计数器和回边计数器。
|
|
|
|
在确定虚拟机运行参数的前提下，这两个计数器都有一个确定的阈值，当计数器超过阈值溢出了，就会触发 JIT 编译。
|
|
|
|
|