虚拟机读书笔记-虚拟机字节码执行引擎

By | 2017年7月22日

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

8.1 概述

  • 执行引擎是Java虚拟机最核心的组成部分之一
  • 虚拟机执行引擎的统一外观:输入的是字节码文件,处理过程是字节码解析的等效过程,输出的是执行结果

8.2 运行时栈帧结构

栈帧是用于支持虚拟机进行方法调用和方法执行的数据结构,它是虚拟机运行时数据区中的虚拟机栈中的栈元素。栈帧存储了方法的局部变量表、操作数栈、动态连接和方法返回地址等信息。每一个方法从调用开始直至执行完成的过程,都对应着一个栈帧在虚拟机栈里面从入栈到出栈的过程。

在编译程序代码的时候,栈帧中需要多大的局部变量表,多深的操作数栈都已经完全确定了,并且写入到方法表的Code属性中,因此一个栈帧需要分配多少内存,不会受到程序运行期变量数据的影响,而仅仅取决于具体的虚拟机实现。

一个线程中的方法调用链可能会很长,很多方法都同时处于执行状态。对于执行引擎来说,在活动线程中,只有位于栈顶的栈帧才是有效的,成为当前栈帧(Current Stack Frame),与这个栈帧相关联的方法成为当前方法(Current Method)。执行引擎运行的所有字节码指令都只针对当前栈帧进行操作。

栈帧的概念模型

8.2.1 局部变量表

  • 局部变量表是一组变量值存储空间,用于存放方法参数和方法内部定义的局部变量
  • 局部变量表的容量以变量槽(Variable Slot)为最小单位
  • 虚拟机通过索引定位的方式使用局部变量表,索引值的范围是从0开始至局部变量表最大的Slot数量
  • 在方法执行时,虚拟机是使用局部变量表完成参数值到参数变量列表的传递过程的,如果执行的是实例方法,那局部变量表中第0位索引的Slot默认是用于传递方法所属对象实例的引用,在方法中可以通过this来访问到这个隐含的参数。其余参数则按照参数表顺序排列,占用从1开始的局部变量Slot,参数表分配完毕后,再根据方法体内部定义的变量顺序和作用域分配其余的Slot
  • 局部变量表中的Slot是可以重用的,在某些情况下,Slot的复用会直接影响到系统的垃圾收集行为
  • 如果一个局部变量定义了但没有赋初始值是不能使用的

8.2.2 操作数栈

  • 后入先出的栈
  • 当一个方法刚刚开始执行的时候,这个方法的操作数栈是空的,在方法的执行过程中,会有各种字节码指令往操作数栈中写入和提取内容,即出栈入栈操作
  • 操作数栈中元素的数据类型必须与字节码指令的序列严格匹配

8.2.3 动态连接

每个栈帧都包含一个指向运行时常量池中该栈帧所属方法的引用,持有这个引用是为了支持方法调用过程中的动态连接。将在8.3节详细讲解。

8.2.4 方法返回地址

当一个方法开始执行后,只有两种方式可以退出这个方法:

  • 正常完成出口:执行引擎遇到任意一个方法返回的字节码指令
  • 异常完成出口:在方法执行过程中遇到异常,并且这个异常没有在方法体内得到处理

无论采用何种退出方式,在方法退出后,都需要返回到方法被调用的位置,程序才能继续执行,方法返回时可能需要在栈帧中保存一些信息,用来帮助恢复它的上层方法的执行状态。

方法退出的过程实际上就等同于把当前栈帧出栈,因此退出时可能执行的操作有:恢复上层方法的局部变量表和操作数栈,把返回值压入调用者栈帧的操作数栈中,调整PC计数器的值以指向方法调用指令后面的一条指令等。

8.2.5 附加信息

虚拟机规范允许具体的虚拟机实现增加一些规范里没有描述的信息到栈帧之中,例如与调试相关的信息。在实际开发中,一般会把动态连接、方法返回地址与其他附加信息全部归为一类,成为栈帧信息。

8.3 方法调用

  • 方法调用并不等同于方法执行,方法调用阶段唯一的任务就是确定被调用方法的版本(即调用哪一个方法),暂时还不涉及方法内部的具体运行过程
  • 在程序运行时,进行方法调用是最普遍、最频繁的操作,Class文件的编译过程不包含传统编译中的连接步骤,一切方法调用在Class文件里面存储的都只是符号引用,这使得Java方法调用过程相对复杂,需要在类加载期间,甚至到运行期间才能确定目标方法的直接引用

8.3.1 解析

  • 所有方法调用中的目标方法在Class文件里面都是一个常量池中的符号引用,在类加载的解析阶段,会将其中的一部分符号引用转化为直接引用,这种解析能成立的前提是:方法在程序真正运行之前就有一个可确定的调用版本,并且这个方法的调用版本在运行期是不可改变的。
  • Java中符号这个要求的方法主要包括静态方法和私有方法两大类,前者与类型直接关联,后者在外部不可被访问。
  • Java虚拟机提供了5条方法调用字节码指令:
    • invokestatic:调用静态方法
    • invokespecial:调用实例构造器<init>方法、私有方法和父类方法
    • invokevirtual:调用所有的虚方法
    • invokeinterface:调用接口方法,会在运行时再确定一个实现此接口的对象
    • invokedynamic:先在运行时动态解析出调用点限定符所引用的方法,然后再执行该方法
  • 只要能被invokestaticinvokespecial指令调用的方法,都可以在解析阶段中确定唯一的调用版本,有静态方法、私有方法、实例构造器、父类方法4类,这些方法可以称为非虚方法
  • 非虚方法除了使用invokestaticinvokespecial调用的方法外还有被final修饰的方法,虽然使用invokevirtual指令调用,但由于它无法被覆盖,没有其他版本,也是一种非虚方法
  • 解析调用一定是一个静态的过程,在编译器件就完全确定,在类加载的解析阶段就会把涉及的符号引用全部转变为可确定的直接引用

8.3.2 分派

分派调用可能是静态也可能是动态,根据分派依据的总量数可分为单分派和多分派。

8.3.2.1 静态分派
package org.fenixsoft.polymorphic;

/**
 * 方法静态分派演示
 */
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);
        sr.sayHello(woman);
    }
}

执行结果:

hello,guy!
hello,guy!

两个重要概念:上述main方法中的Human即为变量的静态类型,或者叫做外观类型;后面的Man则称为变量的实际类型。二者的区别在于静态类型的变化仅仅在使用时发生,变量本身的静态类型不会被改变,并且最终的静态类型是在编译器可知的;而实际类型变化的结果在运行期才可确定,编译器在编译程序时并不知道对象的实际类型。如下代码:

// 实际类型变化
Human man = new Man();
man = new Woman();
// 静态类型变化
sr.sayHello((Man)man);
sr.sayHello((Woman)man);

所有依赖静态类型来定位方法执行版本的分派动作称为静态分派,静态分派的典型应用是方法重载。静态分派发生在编译阶段,确定静态分派的动作实际上是由编译器执行的。编译器虽然能确定出方法的重载版本,但很多情况下只能确定一个“更加适合”的版本。产生这种模糊结论的主要原因是字面量不需要定义,所以字面量没有显示的静态类型,它的静态类型只能通过语言上的规则去理解和推断。

package org.fenixsoft.polymorphic;

/**
 * 重载方法匹配优先级演示
 */
public class OverloadPriority {
    public static void print(Object arg) {
        System.out.println("parameter type = Object");
    }
    public static void print(int arg) {
        System.out.println("parameter type = int");
    }
    public static void print(long arg) {
        System.out.println("parameter type = long");
    }
    
    public static void print(double arg) {
        System.out.println("parameter type = double");
    }
    
    public static void print(float arg) {
        System.out.println("parameter type = float");
    }
    public static void print(char arg) {
        System.out.println("parameter type = char");
    }
    public static void print(Character arg) {
        System.out.println("parameter type = Character");
    }
    public static void print(char... arg) {
        System.out.println("parameter type = char...");
    }
    public static void print(Serializable arg) {
        System.out.println("parameter type = Serializable");
    }
    public static void print(Comparable<?> arg) {
        System.out.println("parameter type = Comparable");
    }
    public static void main(String[] args) {
        // int
        print('g');
    }
}
  • 遇上重载时,会查找类型最匹配的参数,然后提升类型、封装类型、匹配接口、继承关系型、变长参数类型
  • 优先级依次为:char -> int -> long -> double -> float -> Character -> Serializable or Comparable -> Object -> char…(变长参数,即char元素数组)
  • char到byte或short之间的转换是不安全的
  • 在Serializable和Comparable同时存在的情况下会报异常:The method print(Object) is ambiguous for the type OverloadPriority,无法确定应该使用哪一个重载方法,因为Character实现了Serializable和Comparable这两个接口,而接口匹配的优先级是一样的,编译器无法判断转型为哪种类型,提示类型模糊,无法正常编译
  • 接口无法匹配之后,就会开始查找匹配的父类,优先级是顺着继承链,由下往上进行匹配
8.3.2.2 动态分派

动态分派与重写密切相关,代码:

package org.fenixsoft.polymorphic;

/**
 * 方法动态分派演示
 */
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();
    }
}

运行结果:

man say hello
woman say hello
woman say hello

invokevirtual指令执行的第一步就是在运行期确定接收者的实际类型,即把常量池中的类方法符号引用解析到直接引用上,这个过程是Java语言中方法重写的本质。这种在运行期根据实际类型确定方法执行版本的分派过程称为动态分派。

8.3.2.3 单分派与多分派

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

/**
 * 单分派、多分派演示
 */
public class Dispatch {

    static class QQ {}

    static class _360 {}

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

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

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

        public void hardChoice(_360 arg) {
            System.out.println("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());
    }
}

运行结果:

father choose 360
son choose qq
  • 静态分派有两个宗量:一是静态类型是Father还是Son,二是方法参数是QQ还是360,所以Java语言的静态分派属于多分派类型
  • 动态分派只有一个宗量:方法接收者的实际类型是Father还是Son,所以Java语言的动态分派数据单分派类型
8.3.2.4 虚拟机动态分派的实现

由于动态分派是非常频繁的动作,而且动态分派的方法版本选择过程需要运行时在类的方法元数据中搜索合适的目标方法,因此在虚拟机的实际实现中基于性能的考虑,大部分实现都不会真正的进行如此频繁的搜索。最常用的稳定优化手段是为类在方法区中建立一个虚方法表,使用虚方法表索引来代替元数据查找以提高性能。

虚方法表结构

  • 虚方法表中存放着各个方法的实际入口地址,如果某个方法在子类中没有被重写,那子类的虚方法表里面的地址入口和父类相同方法的地址入口是一致的,都指向父类的实现入口;如果子类中重写了这个方法,子类方法表中的地址将会替换为指向子类实现版本的入口地址。
  • 为了程序实现上的方便,具有相同签名的方法,在父类、子类的虚方法表中都应当具有一样的索引序号,这样当类型变换时,仅需变更查找的方法表,就可以从不同的虚方法表中按索引转换出所需的入口地址
  • 方法表一般在类加载的连接阶段进行初始化,准备了类的变量初始值后,虚拟机会把该类的方法表也初始化完毕

8.3.3 动态类型语言支持

JDK7中,为了实现“动态类型语言”支持,同时为JDK8可以顺利实现Lambda表达式做技术准备,增加了invokedynamic指令,

8.3.3.1 动态类型语言
  • 动态类型语言的关键特征是它的类型检查的主体过程是在运行期而不是编译期,如APL、Groovy、js、PHP、Python、Ruby等;相对的,在编译期就进行类型检查过程的语言如C++和Java等就是最常用的静态类型语言。
  • 变量无类型而变量值才有类型
8.3.3.2 JDK1.7与动态类型
  • 目前已经有许多动态类型语言运行于Java虚拟机之上,如Clojure、Groovy、Jython和JRuby等,但Java虚拟机层面对动态类型语言的支持一直有所欠缺
  • JDK1.7(JSR-922)中invokedynamic指令以及java.lang.invoke包便是在此背景下设计出来的
8.3.3.3 java.lang.invoke

主要目的是在之前单纯依靠符号引用来确定调用的目标方法这种方式之外,提供一种新的动态确定目标方法的机制,称为MethodHandle

import static java.lang.invoke.MethodHandles.lookup;

import java.lang.invoke.MethodHandle;
import java.lang.invoke.MethodType;

/**
 * JSR 292 MethodHandle基础用法演示
 */
public class MethodHandleTest {

    static class ClassA {
        public void println(String s) {
            System.out.println(s);
        }
    }

    public static void main(String[] args) throws Throwable {
        Object obj = System.currentTimeMillis() % 2 == 0 ? System.out : new ClassA();
        // 无论obj最终是哪个实现类,下面这句都能正确调用到println方法。
        getPrintlnMH(obj).invokeExact("icyfenix");
    }

    private static MethodHandle getPrintlnMH(Object reveiver) throws Throwable {
        // MethodType:代表“方法类型”,包含了方法的返回值(methodType()的第一个参数)和具体参数(methodType()第二个及以后的参数)。
        MethodType mt = MethodType.methodType(void.class, String.class);
        // lookup()方法来自于MethodHandles.lookup,这句的作用是在指定类中查找符合给定的方法名称、方法类型,并且符合调用权限的方法句柄。
        // 因为这里调用的是一个虚方法,按照Java语言的规则,方法第一个参数是隐式的,代表该方法的接收者,也即是this指向的对象,这个参数以前是放在参数列表中进行传递,现在提供了bindTo()方法来完成这件事情。
        return lookup().findVirtual(reveiver.getClass(), "println", mt).bindTo(reveiver);
    }
}

方法getPrintlnMH()中模拟了invokevirtual指令的执行过程,只不过它的分派逻辑并非固化在Class文件的字节码上,而是通过一个具体方法来实现,而这个方法本身的返回值(MethodHandle对象),可以视为对最终调用方法的一个引用。

MethodHandle与反射的区别:

  • 反射是在模拟Java代码层次的方法调用,而MethodHandle是在模拟字节码层次的方法调用
  • 反射中的java.lang.reflect.Method对象远比MethodHandle机制中的java.lang.invoke.MethodHandle对象所包含的信息多。前者是方法在Java一端的全面映像,包含了方法签名、描述符以及方法属性表中各种属性的java端表示方式,还包含执行权限等的运行期信息。而后者仅仅包含与执行该方法相关的信息。
  • 在虚拟机方面做的各种优化,在MethodHandle上也应当可以采用类似思路去支持,反射则不行。
  • 最关键的区别在于,反射API的设计目标是为Java语言服务的,而MethodHandle则设计成可服务于所有Java虚拟机之上的语言
8.3.3.4 invokedynamic指令
  • invokedynamic指令与MethodHandle机制的作用一样,都是为了解决原有4条invoke*指令方法分派规则固化在虚拟机之中的问题,把如何查找目标方法的决定权从虚拟机转嫁到具体用户代码之中,让用户有更高的自由度。只不过一个是用上层Java代码和API来实现,另一个用字节码和Class中的其他属性、常量来完成。
  • invokedynamic指令所面向的使用者并非Java语言,而是其他Java虚拟机之上的动态语言
8.3.3.5 掌握方法分派规则

invokedynamic指令与其他4条invoke*指令的最大差别就是它的分派逻辑不是由虚拟机决定的,而是由程序员决定的。

import static java.lang.invoke.MethodHandles.lookup;

import java.lang.invoke.MethodHandle;
import java.lang.invoke.MethodType;

class Test {

class GrandFather {
    void thinking() {
        System.out.println("i am grandfather");
    }
}

class Father extends GrandFather {
    void thinking() {
        System.out.println("i am father");
    }
}

class Son extends Father {
     void thinking() {
          try {
                MethodType mt = MethodType.methodType(void.class);
                MethodHandle mh = lookup().findSpecial(GrandFather.class, 
"thinking", mt, getClass());
                mh.invoke(this);
            } catch (Throwable e) {
            }
        }
    }

    public static void main(String[] args) {
        (new Test().new Son()).thinking();
    }
}

运行结果:

i am grandfather

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

8.4.1 解释执行

当前主流的虚拟机都包含了即时编译器,Class文件中的代码到底是解释执行还是编译执行,得视具体的Java实现版本和执行引擎运行模式而定。

编译过程

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

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

Java编译器输出的指令流,基本上是一种基于栈的指令集架构,指令流中的指令大部分都是零地址指令,它们依赖操作数栈进行工作。与之相对的另外一套常用的指令集架构是基于寄存器的指令集,也就是现在主流PC机中直接支持的指令集架构。区别如下:

  • 基于栈的指令集主要的优点是可移植,寄存器由硬件直接提供,程序直接依赖这些硬件寄存器则不可避免的要受到硬件的约束
  • 栈架构的指令集代码相对紧凑、编译器实现更加简单
  • 栈架构指令集执行速度相对稍慢

8.4.3 基于栈的解释器执行过程

public int calc(){
    int a = 100;
    int b = 200;
    int c = 300;
    return (a + b) * c;
}
public int calc();
    flags: ACC_PUBLIC
    Code:
      stack=2, locals=4, args_size=1
         0: bipush        100
         2: istore_1      
         3: sipush        200
         6: istore_2      
         7: sipush        300
        10: istore_3      
        11: iload_1       
        12: iload_2       
        13: iadd          
        14: iload_3       
        15: imul          
        16: ireturn    

javap提示这段代码需要深度为2的操作数栈和4个Slot的局部变量空间,书中花了7张图,描述代码执行过程中操作数栈和局部变量表的变化情况:

执行偏移地址为0的指令的情况

执行偏移地址为1的指令的情况

执行偏移地址为11的指令的情况

执行偏移地址为12的指令的情况

执行偏移地址为13的指令的情况

执行偏移地址为14的指令的情况

执行偏移地址为16的指令的情况

上面的执行过程仅仅是概念模型,与实际情况可能会差距非常大。仅为了描述栈结构指令集的一般运行过程,整个运算过程的中间变量都以操作数栈的出栈、入栈为信息交换途径。

8.5 本章小结

分析了虚拟机在执行代码时,如何找到正确的方法、如何执行方法内的字节码,以及执行代码时涉及的内存结构。

Category: jvm

发表评论