第8章-虚拟机字节码执行引擎

8.1 概述

• 执行引擎是 Java 虚拟机最核心的组成部分之一。“虚拟机” 是一个相对于 “物理机” 的概念，这两种机器都有代码执行能力，其区别是物理机的执行引擎是直接建立在处理器、硬件、指令集和操作系统层面上的，而虚拟机的执行引擎则是由自己实现的，因此可以自行制定指令集与执行引擎的结构体系，并且能够执行那些不被硬件直接支持的指令集格式。
• 在 Java 虚拟机规范中制定了虚拟机字节码执行引擎的概念模型，这个概念模型成为各种虚拟机执行引擎的统一外观（Facade）。在不同的虚拟机实现里面，执行引擎在执行 Java 代码的时候可能会有解释执行（通过解释器执行）和编译执行（通过即时编译器产生本地代码执行）两种选择，也可能两者兼备，甚至还可能会包含几个不同级别的编译器执行引擎。
• 但从外观上看起来，所有的 Java 虚拟机的执行引擎都是一致的：输入的是字节码文件，处理过程是字节码解析的等效过程，输出的是执行结果。

8.2 运行时栈帧结构

8.2.0 概述

1. 栈帧（Stack Frame）是用于支持虚拟机进行方法调用和方法执行的数据结构，它是虚拟机运行时数据区中的虚拟机栈（Virtual Machine Stack）的栈元素。
2. 栈帧存储了方法的局部变量表、操作数栈、动态连接和方法返回地址等信息。每一个方法从调用开始至执行完成的过程，都对应着一个栈帧在虚拟机栈里面从入栈到出栈的过程。（一个方法对应一个栈帧）
3. 在编译程序代码的时候，栈帧中需要多大的局部变量表，多深的操作数栈都已经完全确定了，并且写入到方法表的 Code 属性之中，因此一个栈帧需要分配多少内存，不会受到程序运行期变量数据的影响，而仅仅取决于具体的虚拟机实现。
4. 一个线程中的方法调用链可能会很长，很多方法都同时处于执行状态。对于执行引擎来说，在活动线程中，只有位于栈顶的栈帧才是有效的，称为当前栈帧（Current Stack Frame），与这个栈帧相关联的方法称为当前方法（Current Method）。执行引擎运行的所有字节码指令都只针对当前栈帧进行操作。

8.2.1 局部变量表

1. 局部变量表（Local-Variable-Table）是一组变量值存储空间，用于存放方法参数和方法内部定义的局部变量。
2. 在 Java 程序编译为 Class 文件时，就在方法的 Code 属性的 max_locals 数据项中确定了该方法所需要分配的局部变量表的最大容量。
3. 局部变量表的容量以变量槽（Variable Slot，下称Slot）为最小单位，虚拟机规范中并没有明确指明一个Slot应占用的内存空间大小，只是很有导向性地说到每个Slot都应该能存放一个boolean、byte、char、short、int、float、reference 或returnAddress类型的数据。
4. 对于64位的数据类型，虚拟机会以高位对齐的方式为其分配两个连续的Slot空间。
5. 虚拟机通过索引定位的方式使用局部变量表，索引值的范围是从0开始至局部变量表最大的Slot数量。如果访问的是32位数据类型的变量，索引 n 就代表了使用第n个Slot，如果是64位数据类型的变量，则说明会同时使用n和n+1两个Slot。对于两个相邻的共同存放一个64位数据的两个Slot，不允许采用任何方式单独访问其中的某一个，Java虚拟机规范中明确要求了如果遇到进行这种操作的字节码序列，虚拟机应该在类加载的校验阶段抛出异常。
6. 在方法执行时，虚拟机是使用局部变量表完成参数值到参数变量列表的传递过程的，如果执行的是实例方法（非static的方法），那局部变量表中第0位索引的Slot默认是用于传递方法所属对象实例的引用，在方法中可以通过关键字 “this” 来访问到这个隐含的参数。其余参数则按照参数表顺序排列，占用从1开始的局部变量Slot，参数表分配完毕后，再根据方法体内部定义的变量顺序和作用域分配其余的Slot。
7. 为了尽可能节省栈帧空间，局部变量表中的Slot是可以重用的，方法体中定义的变量，其作用域并不一定会覆盖整个方法体，如果当前字节码PC计数器的值已经超出了某个变量的作用域，那这个变量对应的Slot就可以交给其他变量使用。

8.2.2 操作数栈

1. 操作数栈（Operand Stack）也常称为操作栈，它是一个后入先出（Last In First Out，LIFO）栈。
2. 操作数栈的每一个元素可以是任意的 Java 数据类型，包括 long 和double。32位数据类型所占的栈容量为1，64位数据类型所占的栈容量为2。
3. 操作数栈中元素的数据类型必须与字节码指令的序列严格匹配，在编译程序代码的时候，编译器要严格保证这一点，在类校验阶段的数据流分析中还要再次验证这一点。
4. 以 iadd 指令为例，这个指令用于整型数加法，它在执行时，最接近栈顶的两个元素的数据类型必须为 int 型，不能出现一个 long 和一个 float 使用 iadd 命令相加的情况。
5. 另外，在概念模型中，两个栈帧作为虚拟机栈的元素，是完全相互独立的。但在大多虚拟机的实现里都会做一些优化处理，令两个栈帧出现一部分重叠。让下面栈帧的部分操作数栈与上面栈帧的部分局部变量表重叠在一起，这样在进行方法调用时就可以共用一部分数据，无须进行额外的参数复制传递。

8.2.3 动态连接

1. 每个栈帧都包含一个指向运行时常量池中该栈帧所属方法的引用，持有这个引用是为了支持方法调用过程中的动态连接（Dynamic Linking）。
2. Class文件的常量池中存有大量的符号引用，字节码中的方法调用指令就以常量池中指向方法的符号引用作为参数。
3. 静态解析：符号引用在类加载阶段或者第一次使用的时候转化为直接引用
4. 动态连接：符号引用在每一次运行期间转化为直接引用。

8.2.4 方法返回地址

1. 当一个方法开始执行后，只有两种方式可以退出这个方法。
2. 第一种方式：执行引擎遇到任意一个方法返回的字节码指令，这时候可能会有返回值传递给上层的方法调用者（调用当前方法的方法称为调用者），是否有返回值和返回值的类型将根据遇到何种方法返回指令来决定，这种退出方法的方式称为正常完成出口（Normal Method Invocation Completion）。
3. 另外一种退出方式：在方法执行过程中遇到了异常，并且这个异常没有在方法体内得到处理，只要在本方法的异常表中没有搜索到匹配的异常处理器，就会导致方法退出，这种退出方法的方式称为异常完成出口（Abrupt Method Invocation Completion）。
4. 一个方法使用异常完成出口的方式退出，是不会给它的上层调用者产生任何返回值的。
5. 无论采用何种退出方式，在方法退出之后，都需要返回到方法被调用的位置，程序才能继续执行，方法返回时可能需要在栈帧中保存一些信息，用来帮助恢复它的上层方法的执行状态。
6. 一般来说，方法正常退出时，调用者的 PC 计数器的值可以作为返回地址，栈帧中很可能会保存这个计数器值。
7. 而方法异常退出时，返回地址是要通过异常处理器表来确定的，栈帧中一般不会保存这部分信息。方法退出的过程实际上就等同于把当前栈帧出栈，因此退出时可能执行的操作有：
   • 恢复上层方法的局部变量表和操作数栈
   • 把返回值（如果有的话）压入调用者栈帧的操作数栈中
   • 调整 PC 计数器的值以指向方法调用指令后面的一条指令等。

8.3 方法调用

• 方法调用并不等同于方法执行，方法调用阶段唯一的任务就是确定被调用方法的版本（即调用哪一个方法），暂时还不涉及方法内部的具体运行过程。
• 在程序运行时，进行方法调用是最普遍、最频繁的操作，但前面已经讲过，Class文件的编译过程中不包含传统编译中的连接步骤，一切方法调用在Class文件里面存储的都只是符号引用，而不是方法在实际运行时内存布局中的入口地址（相当于之前说的直接引用）。

8.3.1 解析

1. 所有方法调用中的目标方法在Class文件里面都是一个常量池中的符号引用，在类加载的解析阶段，会将其中的一部分符号引用转化为直接引用，这种解析能成立的前提是：方法在程序真正运行之前就有一个可确定的调用版本，并且这个方法的调用版本在运行期是不可改变的。换句话说，调用目标在程序代码写好、编译器进行编译时就必须确定下来。这类方法的调用称为解析（Resolution）。
2. 在 Java 语言中符合 “编译期可知，运行期不可变” 这个要求的方法，主要包括静态方法和私有方法两大类，前者与类型直接关联，后者在外部不可被访问。
3. 只要能被 invokestatic 和 invokespecial 指令调用的方法，都可以在解析阶段中确定唯一的调用版本，符合这个条件的有静态方法、私有方法、实例构造器、父类方法 4类，它们在类加载的时候就会把符号引用解析为该方法的直接引用。这些方法可以称为非虚方法，与之相反，其他方法称为虚方法（除去 final 方法）
4. 虽然 final 方法是使用 invokevirtual 指令来调用的，但是由于它无法被覆盖，没有其他版本，所以也无须对方法接收者进行多态选择，又或者说多态选择的结果肯定是唯一的。
5. 解析调用一定是个静态的过程，在编译期间就完全确定，在类装载的解析阶段就会把涉及的符号引用全部转变为可确定的直接引用，不会延迟到运行期再去完成。
6. 而分派（Dispatch）调用则可能是静态的也可能是动态的，根据分派依据的宗量数可分为单分派和多分派。这两类分派方式的两两组合就构成了静态单分派、静态多分派、动态单分派、动态多分派4种分派组合情况。

8.3.2 分派

8.3.2.1 静态分派

public class StaticDispatch
{
    static abstract class Human
    {
    }

    static class Man extends Human
    {
    }

    static class Woman extends Human
    {
    }

    public void sayHello(Human guy)
    {
        System.out.println("hello,guy!");
    }

    public void sayHello(Man guy)
    {
        System.out.println("hello,gentleman!");
    }

    public void sayHello(Woman guy)
    {
        System.out.println("hello,lady!");
    }

    public static void main(String[] args)
    {
        Human man = new Man();
        Human woman = new Woman();
        StaticDispatch sr = new StaticDispatch();
        sr.sayHello((Man) man);
        sr.sayHello((Woman) woman);
    }
}

1. 上面代码中的 “Human” 称为变量的静态类型（Static Type），或者叫做外观类型（Apparent Type），后面的 “Man” 则称为变量的实际类型（ActualType）
2. 静态类型和实际类型在程序中都可以发生一些变化，区别是静态类型的变化仅仅在使用时发生，变量本身的静态类型不会被改变，并且最终的静态类型是在编译期可知的
3. 而实际类型变化的结果在运行期才可确定，编译器在编译程序的时候并不知道一个对象的实际类型是什么。
4. main() 里面的两次 sayHello() 方法调用，在方法接收者已经确定是对象 “sr” 的前提下，使用哪个重载版本，就完全取决于传入参数的数量和数据类型。代码中刻意地定义了两个静态类型相同但实际类型不同的变量，但虚拟机（准确地说是编译器）在重载时是通过参数的静态类型而不是实际类型作为判定依据的。
5. 因此，在编译阶段，Javac 编译器会根据参数的静态类型决定使用哪个重载版本，所以选择了 sayHello (Human)作为调用目标，并把这个方法的符号引用写到 main() 方法里的两条 invokevirtual 指令的参数中。
6. 所有依赖静态类型来定位方法执行版本的分派动作称为静态分派。静态分派的典型应用是方法重载。静态分派发生在编译阶段，因此确定静态分派的动作实际上不是由虚拟机来执行的。
7. 另外，编译器虽然能确定出方法的重载版本，但在很多情况下这个重载版本并不是 “唯一的” ，往往只能确定一个 “更加合适的” 版本。这种模糊的结论在由0和1构成的计算机世界中算是比较 “稀罕” 的事情，产生这种模糊结论的主要原因是字面量不需要定义，所以字面量没有显式的静态类型，它的静态类型只能通过语言上的规则去理解和推断。

8.3.2.2 动态分派

public class DynamicDispatch
{
	static abstract class Human
	{
		protected abstract void sayHello()
	}

	static class Man extends Human
	{
		@Override 
		protected void sayHello()
		{
			System.out.println("man say hello");
		}
	}
	
	static class Woman extends Human
	{
		@Override 
		protected void sayHello() 
		{
			System.out.println("woman say hello");
		}
	}
	
	public static void main(String args[])
	{
		Human man = new Man();
		Human woman = new Woman();
		man.sayHello();
		woman.sayHello();
		man = new Woman();
		man.sayHello();
	}
}

1. 显然这里不可能再根据静态类型来决定，因为静态类型同样都是Human的两个变量man和woman在调用 sayHello() 方法时执行了不同的行为，并且变量 man 在两次调用中执行了不同的方法。
2. 导致这个现象的原因很明显，是这两个变量的实际类型不同。
3. 原因要从 invokevirtual 指令的多态查找过程开始说起，invokevirtual指令的运行时解析过程大致分为以下几个步骤：
   • 找到操作数栈顶的第一个元素所指向的对象的实际类型，记作 C。
   • 如果在类型 C 中找到与常量中的描述符和简单名称都相符的方法，则进行访问权限校验，如果通过则返回这个方法的直接引用，查找过程结束；如果不通过，则返回 java.lang.IlegalAccessError 异常。
   • 否则，按照继承关系从下往上依次对 C 的各个父类进行第 2 步的搜索和验证过程。
   • 如果始终没有找到合适的方法，则抛出 java.lang.AbstractMethodError 异常。
4. 由于invokevirtual 指令执行的第一步就是在运行期确定接收者的实际类型，所以两次调用中的invokevirtual指令把常量池中的类方法符号引用解析到了不同的直接引用上，这个过程就是Java语言中方法重写的本质。

8.3.2.3 单分派与多分派

1. 方法的接收者与方法的参数统称为方法的宗量，根据分派基于多少种宗量，可以将分派划分为单分派和多分派两种。
2. 单分派是根据一个宗量对目标方法进行选择，多分派则是根据多于一个宗量对目标方法进行选择。

public class Dispatch
{
	static class QQ {}
	
	static class _360 {}

	public static class Father
	{
		public void hardChoice(QQ arg)
		{
			System.out.printin("father choose qq");
		} 

		public void hardchoice(_360 arg)
		{
			System.out.print1n("father choose 360"); 
		}
	}

	public static class Son extends Father
	{
		public void hardChoice(QQ arg)
		{
			System.out.printin("son choose qq");
		} 

		public void hardchoice(_360 arg)
		{
			System.out.print1n("son choose 360"); 
		}
	}
	
	public static void main(String args[])
	{
		Father father = new Father(); 
		Father son = new Son(); 
		father.hardChoice(new _360()); 
		son.hardChoice(new QQ());
	}
}

3. 我们来看看编译阶段编译器的选择过程，也就是静态分派的过程。这时选择目标方法的依据有两点：

   • 一是静态类型是Father还是Son，
   • 二是方法参数是 QQ 还是 360。

4. 这次选择结果的最终产物是产生了两条 invokevirtual 指令，两条指令的参数分别为常量池中指向Father.hardChoice(360) 及 Father.hardChoice(QQ) 方法的符号引用。因为是根据两个宗量进行选择，所以 Java 语言的静态分派属于多分派类型。

5. 再看看运行阶段虚拟机的选择，也就是动态分派的过程：

   • 在执行 som.hardChoice (new QQ) 这句代码时，更准确地说，是在执行这句代码所对应的 invokevirtual 指令时，由于编译期已经决定目标方法的签名必须为 hardChoice(QQ)，因此这时参数的静态类型、实际类型都对方法的选择不会构成任何影响。
   • 唯一可以影响虚拟机选择的因素只有此方法的接受者的实际类型是 Father 还是 Son。因为只有一个宗量作为选择依据，所以 Java 语言的动态分派属于单分派类型。

6. 根据上述论证的结果，我们可以总结一句：今天的 Java 语言是一门静态多分派、动态单分派的语言。

8.3.2.4 虚拟机动态分派的实现

1. 由于动态分派是非常频繁的动作，而且动态分派的方法版本选择过程需要运行时在类的方法元数据中搜索合适的目标方法，因此在虚拟机的实际实现中基于性能的考虑，大部分实现都不会真正地进行如此频繁的搜索。
2. 面对这种情况，最常用的 “稳定优化” 手段就是为类在方法区中建立一个虚方法表（Vritual Method Table，也称为 vtable，与此对应的，在 invokeinterface 执行时也会用到接口方法表——Inteface Method Table，简称 itable），使用虚方法表索引来代替元数据查找以提高性能。

3. 虚方法表中存放着各个方法的实际入口地址。

   • 如果某个方法在子类中没有被重写，那子类的虚方法表里面的地址入口和父类相同方法的地址入口是一致的，都指向父类的实现入口。
   • 如果子类中重写了这个方法，子类方法表中的地址将会替换为指向子类实现版本的入口地址。

4. 方法表一般在类加载的连接阶段进行初始化，准备了类的变量初始值后，虚拟机会把该类的方法表也初始化完毕。

5. 方法表是分派调用的 “稳定优化” 手段，虚拟机除了使用方法表之外，在条件允许的情况下，还会使用内联缓存（Inline Cache）和基于 “类型继承关系分析”（Class Hierarchy Analysis，CHA）技术的守护内联（Guarded Inlining）两种非稳定的 “激进优化” 手段来获得更高的性能。

8.4 基于栈的字节码解释执行引擎

8.4.1 解释执行

1. 大部分的程序代码到物理机的目标代码或虚拟机能执行的指令集之前，都需要经过下图的各个步骤。图中下面那条分支，就是传统编译原理中程序代码到目标机器代码的生成过程，而中间的那条分支，自然就是解释执行的过程。（绿色代表可选项）

2. 如今，基于物理机、Java虚拟机，或者非Java的其他高级语言虚拟机（HLLVM）的语言，大多都会遵循这种基于现代经典编译原理的思路：

   • 在执行前先对程序源码进行词法分析和语法分析处理，把源码转化为抽象语法树（Abstract Syntax Tree，AST）
   • 对于一门具体语言的实现来说，词法分析、语法分析以至后面的优化器和目标代码生成器都可以选择独立于执行引擎，形成一个完整意义的编译器去实现，这类代表是C/C++语言。
   • 也可以选择把其中一部分步骤（如生成抽象语法树之前的步骤）实现为一个半独立的编译器，这类代表是Java语言。
   • 又或者把这些步骤和执行引擎全部集中封装在一个封闭的黑匣子之中，如大多数的 JavaScript 执行器。

3. Java 语言中，Javac 编译器完成了程序代码经过词法分析、语法分析到抽象语法树，再遍历语法树生成线性的字节码指令流的过程。因为这一部分动作是在 Java 虚拟机之外进行的，而解释器在虚拟机的内部，所以 Java 程序的编译就是半独立的实现。

8.4.2 基于栈的指令集与基于寄存器的指令集

1. Java 编译器输出的指令流，基本上是一种基于栈的指令集架构（Instruction Set Architecture，ISA），指令流中的指令大部分都是零地址指令，它们依赖操作数栈进行工作。
2. 与之相对的另外一套常用的指令集架构是基于寄存器的指令集，最典型的就是 x86 的二地址指令集，说得通俗一些，就是现在我们主流PC机中直接支持的指令集架构，这些指令依赖寄存器进行工作。
3. 基于栈的指令集主要的优点
   • 可移植。因为寄存器由硬件直接提供，程序直接依赖这些硬件寄存器则不可避免地要受到硬件的约束。如果使用栈架构的指令集，用户程序不会直接使用这些寄存器，就可以由虚拟机实现来自行决定把一些访问最频繁的数据（程序计数器、栈顶缓存等）放到寄存器中以获取尽量好的性能，这样实现起来也更加简单一些。
   • 代码相对更加紧凑（字节码中每个字节就对应一条指令，而多地址指令集中还需要存放参数）
   • 编译器实现更加简单（不需要考虑空间分配的问题，所需空间都在栈上操作）等。
4. 栈架构指令集的主要缺点是执行速度相对来说会稍慢一些。所有主流物理机的指令集都是寄存器架构也从侧面印证了这一点。
5. 虽然栈架构指令集的代码非常紧凑，但是完成相同功能所需的指令数量一般会比寄存器架构多，因为出栈、入栈操作本身就产生了相当多的指令数量。更重要的是，栈实现在内存之中，频繁的栈访问也就意味着频繁的内存访问，相对于处理器来说，内存始终是执行速度的瓶颈。尽管虚拟机可以采取栈顶缓存的手段，把最常用的操作映射到寄存器中避免直接内存访问，但这也只能是优化措施而不是解决本质问题的方法。