JVM之执行引擎

最新推荐文章于 2024-08-25 17:15:00 发布

lightj1996

最新推荐文章于 2024-08-25 17:15:00 发布

阅读量233

点赞数

CC 4.0 BY-SA版权

本文链接：https://blog.youkuaiyun.com/lightj1996/article/details/107082076

本文深入探讨JVM执行引擎的工作原理，包括字节码解释器和即时编译器(JIT)的角色，以及它们如何协作提高Java应用程序的性能。介绍了热点代码探测、分层编译策略和Graal编译器的最新进展。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

返回主博客

概述

执行引擎充当字节码的翻译者，与操作系统打交道，并执行代码。

执行引擎在执行过程中究竟需要执行什么指令完全依赖PC寄存器
每当执行玩一项指令操作后，PC寄存器会更新下一条需要被执行的指令地址
每当方法在执行过程中，执行引擎可能会通过存储在局部变量表中的对象引用准确定位到存储在堆区的对象实例信息，以及通过对象头中的元数据指针定位到对象的类型信息。

两条途径

执行引擎执行字节码指令可以用两条途径

1、使用解释器（interpreter）对字节码进行解释执行、

2、使用即时编译器（JIT Compiler），将字节码编译成机器指令后再执行。

起初在Sun Classic VM中只使用解释器，后来在HOTSPOT之后二者结合使用。如下图

java代码编译和执行的过程

前端编译器：图中黄色部分就是前端编译器所作事情，将java编译成class

JIT编译器：图中蓝色部分。

解释器：图中绿色部分。

AOP编译器：黄色+绿色部分，直接将java文件编译为机器指令。

解释器

承担运行时的翻译者，将class文件翻译成对应平台的机器指令执行。当一条字节码指令被解释执行完成之后，接着再根据PC寄存器的下一条直接进行解释操作。

为什么要有class文件，JVM为什么不直接解释java文件？

1、java执行中依赖的指令集架构是基于栈的指令集架构。程序在运行时是依赖对于栈的操作的。就好比我们在科学计算器中输入一串式子：(((1+2)*(2+3)+4*5)*3让计算器计算。计算器需要对这串的每个操作和数字进行分析，遇到优先级低的操作符时需要将数字入栈，遇到操作符优先级高的则取栈顶元素计算，然后计算结果入栈。java的基于栈的指令集架构就类似于科学计算器算法。就是出栈运算，结果入栈。但是对于这串式子的解析和判断优先级是要耗时的，所以我们可以直接将其编译，生成那些对栈的操作指令，这样在实际运行的时候便快一点。java也是如此，直接将java文件交给JVM运行，需要对其进行语法词法分析，这是相当耗时的。
2、java不仅是跨平台的语言，并且JVM是一个跨语言的平台，其他自开发语言都可以编译成class文件交给JVM运行。比如Scala、Kotlin、Groovy、Jython。

两套解释器

java的历史进程中有两套解释器，古老的字节码解释器，和现在普遍使用的模板解释器。

1、字节码解释器：

通过纯软件代码模拟字节码的执行，就是读到字节码时，先翻译这行字节码的意思，比如 “iload_1”，那么就是纯执行C语言代码，operationStack.push(local[1])。

2、模板解释器：

将字节码和一个模板函数相关联，比如 “iload_1", 这个iload和一个映射到了一个函数指针，直接就对应运行上了。这个模板函数就直接对应了其字节码执行需要的机器指令。

如下图，就是Jpython的字节码解释用到的模板，器中Load_FAST，Load_CONST等就是用是C语言实现的模板，其映射了一类字节码指令。

在hotspot虚拟机中，解释器主要由Interpreter模块和Code模块组成。

Interpreter实现解释器核心功能。
Code模块用于管理HotSpot在运行时生成的本地机器指令。

JIT编译器

对字节码逐行解释执行时很慢的，为了解决这个问题，JVM支持即时编译的技术，可以将整个函数编译为机器码，函数执行时，每次执行机器码即可。

何时选择JIT编译器？热点代码及其探测方式：

根据代码的执行频率而定，将频率高的编译为本地本地代码，这部分代码称为热点代码。一个频繁被执行的方法或循环次数较多的循环体，可以被称为热点代码。将这部分代码编译为机器指令，这个过程称为“栈上替换”或OSR（On Stack Replacement）。目前HotSpot的热点探测方式为基于计数器的热点探测。JVM为每个方法都建立两个不同类型的计数器。（我们操作系统好像使用的时换页算法）

方法调用计数器：统计方法调用次数
回边计数器：统计循环体循环次数

计数器的默认阈值在clent模式下是1500，在service模式是10000，可以用XX:CompileThreshold控制。

如果不加任何设置，这个统计计数值，是会衰减的，当超过一定的时间限度（半衰期），该方法或者循环体不能到达阈值，会衰减至原来一半，也就是说我们这个时间计数是统计在某一限定范围的被调用次数。（个人感觉这个不合理，既然你已经认为他不好达到阈值，为什么还要统计，统计完还得给他衰减一半，假如它有被调用还得count++）

可以用-XX:UseCounterDecay=false关闭衰减。
可以用-XX:CounterHalfFifeTime 设置半衰期。

方法计数器的控制大致过程如下图：

回边计数器的控制过程如下图

注意

1、图中的codeCache存储在方法区的元空间。
2、回边计数器值是与方法计数器值求和生效的。

C1和C2

hotSpot内嵌两个JIT编译器：client Compiler 和 server Compiler，简称C1和C2。可以通过一下参数设置

-client：对字节码简单可靠的优化，耗时短，64位操作系统下配置-client会被忽略。

-server：对字节码执行更加耗时和激进的优化，但执行效率更高，默认64为操作系统下为server，即使配置-client也会被忽略。

C1和C2的不同优化策略

C1：

方法内敛：将引用的函数代码编译到引用点处，这样可以减少栈帧的生成，减少参数传递以及跳转过程。
去虚拟化：对唯一的实现类进行内联
冗余消除：将运行期间不会执行和逻辑上无效的代码折叠。

C2：优化主要在全局层面，逃逸分析是优化的基础。基于逃逸分析有以下优化。（C++编写）

标量分离
同步消除
栈上分配

分层编译策略

程序解释运行，如果不开启性能监控，可以触发C1编译，可以简单优化。如果开启性能监控，C2会根据性能监控信息进行激进优化。如果激进优化失败，会退回到解释执行。

在jdk1.7之后，如果指定-server，默认会开启分层编译策略，C1和C2相互协作共同执行编译任务。

总结

一般来说，JIT编译出来的机器码性能比解释器高。
C2编译器启动时长比C1慢，系统稳定执行之后，C2编译器的执行速度远远快于C1编译器

解释器和JIT编译器

解释器和JIT编译器需要配合使用才可可以在普遍场景下高效。因为编译需要时间，如果要等编译完在执行，就像纸上谈兵，只谈规划不执行，规划好久之后才执行，后面执行很快，但是启动速度。使用解释器就好像不做规划就冲动执行，但是在执行过程中速度很慢。二者结合才可高效。如下图，二者就像执行引擎的两条腿。（就像我们写代码一样不能只干想等想好再写，也不能想都不想，写到哪里算哪里）