Java JVM 动态方法调用指令 invokedynamic 实现分析（以 Lambda 表达式实现原理为例）

一个会写诗的程序员

发布于 2022-01-27 19:41:16

9450

发布于 2022-01-27 19:41:16

文章被收录于专栏：一个会写诗的程序员的博客一个会写诗的程序员的博客

一、前言

对于 invokedynamic 指令的实现需要方法句柄作为前提知识点。可参考 Java JVM 动态方法调用之方法句柄 MethodHandle。

本文以 Lambda 表达式中运用 invokedynamic 的实现分析。

二、通过简单的代码分析

class InvokeDynamicExample {
    public void lambda1() {
        Runnable runnable = () -> {
            int i = 1;
        };
        runnable.run();
    }
}

转为字节码后，关键字节码如下：

{
  public void lambda1();
    Code:
      stack=1, locals=2, args_size=1
         0: invokedynamic #2,  0     // 生成动态调用站点
         5: astore_1
         6: aload_1
         7: invokeinterface #3,  1  // 调用 lambda 表达式
        12: return
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0      13     0  this   LInvokeDynamicExample;
            6       7     1 runnable   Ljava/lang/Runnable;

  private static void lambda$lambda1$0(); // Runnable lambda 表达式默认生成的方法
    Code:
      stack=1, locals=1, args_size=0
         0: iconst_1
         1: istore_0
         2: return
}
BootstrapMethods:  // 引导方法
  0: #23 invokestatic   // 调用静态方法 LambdaMetafactory.metafactory() 返回 CallSite 对象
    Method arguments: // 静态方法关联参数
      #24 ()V
      #25 invokestatic InvokeDynamicExample.lambda$lambda1$0:()V
      #24 ()V

大体流程：

javac 编译期间将 Lambda 表达式内容编译为一个新的方法，如果表达式与外部成员变量没有关联，编译为静态方法，否则编译为非静态方法。上述示例被编译为 private static void lambdalambda10 静态方法。
代码执行 invokedynamic 指令时，将调用常量池对应的 BootstrapMethods(引导方法) ，引导方法返回一个动态调用站点对象 CallSite，该对象绑定了要执行的方法句柄。上述示例引导方法为 #23 LambdaMetafactory.metafactory ，该方法返回一个动态调用站点对象 CallSite
动态调用站点对象 CallSite 上绑定了 lambdalambda10 方法相关的信息（参考字节码 #25）。
之后执行 runnable.run(); 代码时，虚拟机则直接调用已经绑定了调用点所链接的 lambdalambda10 方法。

参考

动态调用站点 CallSite 对象有关的更多字段类型可参考 AbstractValidatingLambdaMetafactory 类定义。
官方-Using the invokedynamic Instruction
Java 8 的 Lambda 表达式为什么要基于 invokedynamic？

附: Java 源代码怎么执行的

许多 Java 虚拟机的执行引擎在执行 Java 代码的时候都是解释执行（通过解释器执行）和编译执行（通过即时编译器产生本地代码执行）混合运行。

大体流程为：

编写 java 文件源码
通过 javac 编译器将 java 源码编译为字节码流
通过解释器解释执行字节码
随着时间推移，即时编译器 (JIT) 介入，把越来越多的字节码编译成本地代码（机器码）执行

本文中无特殊说明，编译器指即时编译器，即在运行期间的编译。

二、解释器是怎么解释字节码流执行的

我们使用 javac 编译器编译完后会生成字节码流，这些字节码解释执行方式有 2 种。一种是基于栈的指令集，一种是基于寄存器的指令集。

比如一个 1 + 1 的计算。

基于栈的指令集时：

iconst_1    将 1 放入栈顶
iconst_1    将 1 放入栈顶
iadd        将栈顶的 2 个数相加后结果放入栈顶
istore_0    将相加的结果放入局部变量表

基于寄存器的指令集时：

mov eax,1 把 EAX 寄存器的值设为 1
add eax,1 再把这个值加 1 ，结果保存在了 EAX 寄存器

两套指令集的优缺点：

基于栈的指令集优点是可移植，因为寄存器由硬件直接提供，受到硬件的约束。
基于栈的指令集缺点理论上执行速度可能较慢，出栈入栈本身就涉及了大量的指令，而且栈是在内存中实现的。

实际中基于栈的指令集会被虚拟机优化，比如使用即时编译，常用操作映射到寄存器。

三、编译器是如何将字节码编译为本地机器码的

服务端编译器和客户端编译器的编译过程是有所差别。

对于客户端编译器来说：

它是一个相对简单快速的三段式编译器，主要的关注点在于局部性的优化，而放弃了许多耗时较长的全局优化手段。

在第一个阶段，一个平台独立的前端将字节码构造成一种高级中间代码表示（High-Level Intermediate Representation，HIR，即与目标机器指令集无关的中间表示）。 HIR 使用静态单分配（Static Single Assignment，SSA）的形式来代表代码值，这可以使得一些在 HIR 的构造过程之中和之后进行的优化动作更容易实现。在此之前编译器已经会在字节码上完成一部分基础优化，如方法内联、常量传播等优化将会在字节码被构造成 HIR 之前完成。

在第二个阶段，一个平台相关的后端从 HIR 中产生低级中间代码表示（Low-Level Intermediate Representation，LIR，即与目标机器指令集相关的中间表示），而在此之前会在 HIR 上完成另外一些优化，如空值检查消除、范围检查消除等，以便让 HIR 达到更高效的代码表示形式。

最后的阶段是在平台相关的后端使用线性扫描算法（Linear Scan Register Allocation）在 LIR 上分配寄存器，并在 LIR 上做窥孔（Peephole）优化，然后产生机器代码。

对于服务端编译器来说：

服务端编译器则是专门面向服务端的典型应用场景，并为服务端的性能配置针对性调整过的编译器，也是一个能容忍很高优化复杂度的高级编译器，几乎能达到 GNU C++ 编译器使用-O2 参数时的优化强度。它会执行大部分经典的优化动作，如：无用代码消除、循环展开、循环表达式外提、消除公共子表达式、常量传播、基本块重排序等，还会实施一些与 Java 语言特性密切相关的优化技术，如范围检查消除、空值检查消除等。另外，还可能根据解释器或客户端编译器提供的性能监控信息，进行一些不稳定的预测性激进优化，如守护内联、分支频率预测等

服务端编译采用的寄存器分配器是一个全局图着色分配器，它可以充分利用某些处理器架构（如 RISC）上的大寄存器集合。以即时编译的标准来看，服务端编译器无疑是比较缓慢的，但它的编译速度依然远远超过传统的静态优化编译器，而且它相对于客户端编译器编译输出的代码质量有很大提高，可以大幅减少本地代码的执行时间，从而抵消掉额外的编译时间开销，所以也有很多非服务端的应用选择使用服务端模式的 HotSpot 虚拟机来运行。