JVM执行引擎
执行引擎的概述
- 执行引擎是Java虚拟机核心的组成部分之一。
- “虚拟机”是一个相对于“物理机”的概念,这两种机器都有代码执行能力,其区别是物理机的执行引擎是直接建立在处理器、缓存、指令集和操作系统层面上的,而**虚拟机的执行引擎则是由软件自行实现的,**因此可以不受物理条件制约地定制指令集与执行引擎的结构体系,能够执行那些不被硬件直接支持的指令集格式。
- 执行引擎的任务就是将字节码指令解释/编译为对应平台上的本地机器指令。
- 从外观上看,所有的Java虚拟机的执行引擎输入、输出都是一致的:输入的是字节码的二进制流,处理过程是字节码解析执行的等效过程,输出的是执行结果。
Java代码编译和执行的过程
解释器:
当Java虚拟机启动时会根据定义的规范对字节码采用逐行解释的方式执行,将每条字节码文件中的内容“翻译”为对应平台的本地机器指令执行。
JIT编译期:
JIT(Just In Time Compiler)编译期:就是虚拟机将源代码直接编译成本地机器平台相关的机器语言。
机器码、指令、汇编语言
机器码:
- 各种用二进制编码方式表示的指令,叫做机器指令码。开始,人们用它编写程序,这就是机器语言。
- 机器语言虽然能够被计算机理解和接受,但和人类语言差别太大,不利于理解记忆,且用它编程易出错。
- 用它编写的程序一经输入计算机,CPU直接读取运行,因此和其他语言编的程序相比,执行速度最快。
- 机器指令与CPU紧密相关,所以不同种类的CPU对应的机器指令不同。
指令,指令集:
指令:
- 由于机器码是有0和1组成的二进制序列,可读性太差,于是人们发明了指令。
- 指令就是把机器码中特点的0和1序列,简化成对应的指令(一般为英文简写,如mov,inc等),可读性稍好。
- 由于不同的硬件平台,执行同一个操作,对应的机器码可能不同,所以不同的硬件平台的同一种指令,对应机器码可能也不同。
指令集:
- 不同的硬件平台,各自支持的指令,是有差别的。因此每个平台所支持的指令,称之为对应平台的指令集。
- 如常见的:
- x86指令集
- ARM指令集
汇编语言:
- 由于指令的可读性还是太差,人类发明了汇编语言。
- 在汇编语言中,用助记符(Mnemonics)代替机器指令的操作码,用地址符号(Symbol)或标号(Label)代替指令或操作数的地址。
- 在不同的硬件平台,汇编语言对应着不同的机器语言指令集,通过汇编过程转换成机器指令。
- 由于计算机只认识指令码,所以汇编语言编写的程序必须翻译成机器指令码,计算机才能识别和执行。
高级语言:
- 为了使计算机用户编程更容易,出现了各种高级语言。高级语言相比机器语言、汇编语言更接近人的语言。
- 当计算机执行高级语言程序时,仍然需要把程序解释和编译成机器的指令码。完成这个过程的程序就叫做解释程序或编译程序。
高级语言执行过程:
字节码:
- 是一种中间状态(中间码)的二进制代码(文件),比机器码更抽象,需要直译器转译后才能成为机器码。
- 字节码主要为了实现特定软件运行和软件环境、与硬件环境无关。
字节码的实现方式是通过编译器和虚拟机器。编译器将源代码编译成字节码,特定平台上的虚拟机将字节码转译为可以直接执行的指令。
解释器
JVM设计者们初衷仅仅是单纯的为了满足Java程序实现跨平台特性,因此避免采用静态编译的方式直接生成本地机器指令,从而诞生了实现解释器在运行时采用逐行解释字节码执行程序的想法。
- 解释器真正意义上所承担的角色就是一个运行时“翻译者”,将字节码文件中的内容“翻译”为对应平台的本地机器指令执行。
- 当一条字节码指令被解释执行完成后,接着再根据PC寄存器中记录的下一条需要被执行的字节码指令执行解释操作。
在Java的发展历史里,一共有两套解释执行器,即古老的字节码解释器、现在普遍使用的模板解释器。
- 字节码解释器在执行时通过纯软件代码模拟字节码的执行,效率非常低下。
- 模板解释器将每一条字节码和一个模板函数关联,模板函数中直接产生这条字节码执行时的机器码,从而很大程度上提高了解释器的性能。
在HotSpot VM中,解释器主要由Interceptor模块和Code模块构成
-> Interceptor模块:实现了解释器的核心功能
-> Code模块:用于管理HotSpot VM在运行时生成的本地机器指令
现状:
- 基于解释器的执行已经沦为低效的代名词。
- 为了解决该问题,JVM平台支持一种叫做即时编译的技术。即时编译的目的是避免函数被解释执行,而是将整个函数体编译为机器码,每次函数执行时,只执行编译后的机器码即可。
JIT编译器
理解执行引擎:
Java代码的执行分类:
- 第一种是将源代码编译成字节码文件,然后在运行时通过解释器将字节码转为机器码执行
- 第二种是编译执行(直接编译成机器码)。现代虚拟机为了提高执行效率,会采用即时编译技术(Just In Time)将方法编译成机器码后在执行。
HotSpot VM 采用解释器与即时编译器并存的架构。在Java虚拟机运行时,解释器和即时编译器能相互协作执行,各自取长补短。
目前Java运行程序,已经可以和C/C++程序一较高下。
为什么HotSpot中已经内置JIT编译器,还需要使用解释器拖累程序性能?
- 当程序启动后,解释器可以马上发挥作用,省去编译时间,立即执行。
- 编译器要想发挥作用,把代码编译成本地代码,需要一定执行时间。但编译为本地代码后,执行效率更高。
- 当Java虚拟机启动时,解释器可以先发挥作用,而不必等待即时编译器全部编译完成后再执行,这样可以省去许多不必要的编译时间。随着时间的推移,编译器发挥作用,把越来越多的代码编译成本地机器码,获得更高的执行效率。
- 同时,解释执行在编译期进行激进优化不成立时,作为后备方案。
案例:
机器在热机状态可承受的负载要大于冷机状态。如发布时,分批次发布错误称为两批次发布,热机勉强可以承受流量,但由于刚启动JVM都是解释执行,还没有进入热点代码统计和JIT动态编译,所以导致服务器宕机。
概念解释
- Java语言的“编译期”起始是一段不确定的操作过程,因为它可能是指一个前端编译器(编译期的前端)把 .Java 文件转变成 .class 文件的过程。
- 也可能是指虚拟机的后端运行编译器(JIT编译器)把字节码转变成机器码的过程。
- 还可能是指静态提前编译器(AOT编译器,Ahead Of Time Compiler)直接把 .Java 文件编译成本地机器代码的过程。
附:前端编译器:Sun的Javac,Eclipse JDT中的增量式编译期(EJC)
JIT编译器:HotSpot VM的C1,C2编译器
AOT编译器:GNU Compiler for the Java(GCJ),Excelsior JET
热点代码及探测方式
是否需要启动JIT编译器将字节码直接编译为对应平台的本地机器指令,则需要根据代码被调用执行的频率而定。关于那些需要被编译为本地代码的字节码,称为**“热点代码”,JIT编译器在运行时会针对那些频繁被调用的热点代码进行深度优化,将其直接编译为对应平台的本地机器指令,以此提升Java程序的执行性能。
- 一个被多次调用的方法,或者一个方法体内部循环次数较多的循环体都可以被称之为“热点代码”,因此都可以通过JIT编译期编译为本地机器指令。由于这种编译方式发生在方法执行过程中,因此也称为栈上替换,或称为OSR(On Stack Replacement)编译。
- 一个方法究竟要被调用多少次,或一个循环究竟要执行多少次循环才可以达到这个标准?必然需要一个阈值,JIT编译器才会将这些“热点代码”编译为本地机器指令。这里主要依靠热点探测功能。
- 目前HotSpot VM所采用的的热点探测方式是基于计数器的热点探测。
- 采用基于计数器的热点探测,HotSpot VM会将每一个方法都建立2个不同类型计数器,分别为方法调用计数器(Invocation Counter)和回边计数器(Back Edge Counter)。
- 方法调用计数器用于统计方法调用的次数。
- 回边计数器用于统计循环体的执行的循环次数。
方法调用计数器
- 这个计数器就用于统计方法被调用的次数,默认阈值在Client模式1500次,Server模式10000次,超过阈值触发JIT编译。
- 这个阈值可以通过 -XX:CompileThreshold 认为设定。
当一个方法被调用时,会先检查该方法是否存在被JIT编译过的版本,如果不存在,则优先使用编译后的本地代码来执行。如果不存在已被编译过的版本,则将此方法的调用计数器加1,然后判断方法调用计数器与回边计数器之和是否超过方法调用计数器阈值。如果超过,那么将会向JIT编译器提交一个该方法的代码编译请求。
热度衰减
- 如果不做任何设置,那么方法调用计数器统计的并不是方法被调用的绝对次数,而是一个相对的执行频率,即一段时间之内方法被调用的次数。当超过一定的时间限度,如果方法的调用次数仍然不足以让它提交给即时编译器编译,那这个方法的调用计数器就会少一半,这个过程称为方法的调用计数器热度的衰减,而这段时间就称为此方法统计的半衰周期。
- 进行热度衰减的动作实在虚拟机进行垃圾回收时顺便进行的,可以使用虚拟机参数 -XX:-UseCounterDecay 来关闭热度衰减,让方法计数器统计方法调用的绝对次数,这样,只要系统运行时间足够长,绝大部分方法都会被编译成本地代码。
- 另外,可以使用 -XX:CounterHalfLifeTime 参数设置半衰周期的时间,单位是秒。
回边计数器
作用是统计一个方法中循环体代码执行的次数,在字节码中遇到控制流向后跳转的指令称为回边(Back Edge)。显然,建立回边计数器统计的目的是为了触发OSR编译。
HotSpot VM可以设置程序执行方式
缺省情况下HotSpot VM采用解释器与JIT编译器并存的架构。开发人员可以通过命令显示指定:
- -Xint :完全采用解释器模式执行程序。
- -Xcomp :完全采用即时编译器模式执行程序。如果即时编译出现问题,解释器会介入执行。
-Xmixed :采用解释器+即时编译器的混合模式共同执行程序。
HotSpot VM中JIT分类
HotSpot VM内嵌2个JIT编译器,分别为Client Compiler和Server Compiler,多数情况下简称为C1和C2编译器。开发人员可以显示指定:
- -client:指定Java虚拟机运行在Client模式下,并使用C1编译器。
- C1编译器会对字节码进行简单和可靠的优化,耗时短。 以达到更快编译速度。
- -server:指定Java虚拟机运行在Server模式下,并使用C2编译器。
- C2进行耗时较长的优化,以及激进优化。 但优化的代码执行效率更高。
C1和C2编译器不同的优化策略
- C1编译器上主要有方法内联,去虚拟化、冗余消除。
- 方法内联:将引用的函数代码编译到引用点处,这样可以减少栈帧的生成,减少参数传递以及跳转过程
- 去虚拟化:对唯一的实现类进行内联
- 冗余消除:在运行期间把一些不会执行的代码折叠掉
- C2的优化主要是在全局层面,逃逸分析是优化的基础。基于逃逸分析在C2上有如下几种优化:
- 标量替换:用标量值代替聚合对象的属性值
- 栈上分配:对于未逃逸的对象分配在栈上而不是堆中
- 同步消除:消除同步操作(通常指synchronized)
分层编译策略(Tiered Compilation)
-
- 程序解释执行时(不开启性能监控),可以触发C1编译,将字节码编译成机器码,可以进行简单优化,也可以加上性能监控,C2编译会根据性能监控信息进行激进优化。
- 在JDK7以后,一般以-server模式启动,默认开启分层编译策略。

浙公网安备 33010602011771号