【笔记】JVM之执行引擎

2020-07-15 | 阅读：次 |本站总访问量次 | 本站访客数人

1.执行引擎概述

执行引擎是Java虚拟机核心的组成部分之一
“虚拟机”是一个相对于“物理机”的概念，这两种机器都有代码执行能力，其区别是物理机的执行引擎是直接建立在处理器、缓存、指令集和操作系统层面上的，而虚拟机的执行引擎则是由软件自行实现的，因此可以不受物理条件制约地定制指令集与执行引擎的结构体系,能够执行那些不被硬件直接支持的指令集格式。
JVM的主要任务是负责装载字节码到其内部，但字节码并不能够直接运行在操作系统之上，因为字节码指令并非等价于本地机器指令，它内部包含的仅仅只是一些能够被JVM所识别的字节码指令、符号表，以及其他辅助信息。
那么，如果想要让一个Java程序运行起来，执行引擎（Execution Engine）的任务就是将字节码指令解释/编译为对应平台上的本地机器指令才可以。简单来说，JVM中的执行引擎充当了将高级语言翻译为机器语言的译者。

执行引擎的工作过程

从外观上来看，所有的Java虚拟机的执行引擎输入、输出都是一致的：输入的是字节码二进制流，处理过程是字节码解析执行的等效过程，输出的是执行结果。

2.Java代码编译和执行过程

问题：什么是解释器（Interpreter）,什么是JIT编译器？

解释器:当Java虚拟机启动时会根据预定义的规范对字节码采用逐行解释的方式执行,将每条字节码文件中的内容“翻译”为对应平台的本地机器指令执行。

JIT(及时)（Just In Time Compiler）编译器：就是虚拟机将源代码直接编译成和本地机器平台相关的机器语言。

3.机器码、指令、汇编语言

机器码

指令和指令集

汇编语言

高级语言

字节码

C、C++源程序执行过程：

4.解释器

解释器工作机制（或工作任务）

解释器真正意义上所承担的角色就是一个运行时“翻译者”,将字节码文件中的内容“翻译”为对应平台的本地机器指令执行
当一条字节码指令被解释执行完成后，接着再根据PC寄存器中记录的下一条需要被执行的字节码指令执行解释操作。

解释器分类

现状

5.JIT编译器

Java代码的执行分类

jconsole查看：JIT

JIT编译器概念

如何选择？

热点代码及探测方式

方法调用计数器

热度衰减

回边计数器

HotSpot VM可以设置程序执行方式

缺省情况下HotSpot VM是采用解释器与即时编译器并存的架构，当然开发人员可以根据具体的应用场景，通过命令显式地为Java虚拟机指定在运行时到底是完全采用解释器执行，还是完全采用即时编译器执行。如下所示: ➢-Xint: 完全采用解释器模式执行程序; ➢-Xcomp: 完全采用即时编译器模式执行程序。如果即时编译出现问题，解释器会介入执行。 ➢-Xmixed: 采用解释器+即时编译器的混合模式共同执行程序。

/**
 * 测试解释器模式和JIT编译模式
 *  -Xint  : 6520ms
 *  -Xcomp : 950ms
 *  -Xmixed : 936ms
 */
public class IntCompTest {
    public static void main(String[] args) {

        long start = System.currentTimeMillis();

        testPrimeNumber(1000000);

        long end = System.currentTimeMillis();

        System.out.println("花费的时间为：" + (end - start));

    }

    public static void testPrimeNumber(int count){
        for (int i = 0; i < count; i++) {
            //计算100以内的质数
            label:for(int j = 2;j <= 100;j++){
                for(int k = 2;k <= Math.sqrt(j);k++){
                    if(j % k == 0){
                        continue label;
                    }
                }
                //System.out.println(j);
            }

        }
    }
}

HotSpot VM中的JIT分类

在HotSpot VM中内嵌有两个JJT编译器，分别为Client Compiler和Server Compiler,(64位操作系统默认就是Server Compiler)但大多数情况下我们简称为C1编译器和C2编译器。开发人员可以通过如下命令显式指定Java虚拟机在运行时到底使用哪一种即时编译器，如下所示:

●-client:指定Java虚拟机运行在Client模式下，并使用C1编译器; ➢C1编译器会对字节码进行简单和可靠的优化，耗时短。以达到更快的编译速度。 ●-server:指定Java虚拟机运行在Server模式下，并使用C2编译器。（C++编写的） ➢C2进行耗时较长的优化，以及激进优化。但优化的代码执行效率更高。

C1和C2编译器不同的优化策略

在不同的编译器上有不同的优化策略，C1编译器上主要有方法内联，去虚拟化、冗余消除。

>➢方法内联:将引用的函数代码编译到引用点处，这样可以减少栈帧的生成，减少参数传递以及跳转过程
  	>➢去虚拟化:对唯一的实现类进行内联
  	>➢冗余消除:在运行期间把一些不会执行的代码折叠掉

C2的优化主要是在全局层面，逃逸分析是优化的基础。基于逃逸分析在C2上有如下几种优化:

➢标量替换:用标量值代替聚合对象的属性值 ➢栈上分配:对于未逃逸的对象分配对象在栈而不是堆 ➢同步消除:清除同步操作，通常指synchronized

分层编译(Tiered Compilation)策略
:程序解释执行(不开启性能监控)可以触发C1编译，将字节码编译成机器码，可以进行简单优化，也可以加上性能监控，C2编译会根据性能监控信息进行激进优化。

不过在Java7版本之后，一旦开发人员在程序中显式指定命令“-server”时，默认将会开启分层编译策略，由C1编译器和C2编译器相互协作共同来执行编译任务。

总结

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

写在最后

●自JDK10起，HotSpot又加入一个全新的即时编译器: Graal编译器。 ●编译效果短短几年时间就追评了C2编译器。未来可期。 ●目前，带着“实验状态”标签，需要使用开关参数

-XX: +UnlockExperimentalVMOptions -XX: +UseJVMCICompiler

去激活，才可以使用。

关于AOT编译器

jdk9引入了AOT编译器(静态提前编译器，Ahead Of Time Compiler)
Java 9引入了实验性AOT编译工具jaotc。(.class- >. so)它借助了Graal 编译器，将所输入的Java 类文件转换为机器码，并存放至生成的动态共享库之中。
所谓AOT编译，是与即时编译相对立的一一个概念。我们知道，即时编译指的是在程序的运行过程中，将字节码转换为可在硬件上直接运行的机器码，并部署至托管环境中的过程。而AOT编译指的则是，在程序运行之前，便将字节码转换为机器码的过程。 .java ->.class- >. so
最大好处: Java虚拟机加载已经预编译成二进制库，可以直接执行。不必等待即时编译器的预热，减少Java应用给人带来“第-.次运行慢”的不良体验。
缺点:

➢破坏了java”一次编译，到处运行”，必须为每个不同硬件、OS编译对应的发行包。 ➢降低了Java链接过程的动态性，加载的代码在编译期就必须全部已知。 ➢还需要继续优化中，最初只支持Linux x64 java base

肖申克赫本