时间戳

首页 > 解决方案 > 垃圾收集器如何更新推送到操作数堆栈的引用？

java - 垃圾收集器如何更新推送到操作数堆栈的引用？

问题描述

JVM在堆中移动对象时可以方便地更新局部变量、静态引用、类实例或对象数组实例的引用。但是它如何更新推送到操作数堆栈的引用呢？

标签： javagarbage-collectionjvmbytecode

解决方案

局部变量和操作数堆栈中的条目之间没有根本区别。两者都存在于同一个堆栈帧中。两者都没有正式声明，并且都需要 JVM 执行推理以识别它们的实际用途。

以下代码

public static void example() {
    {
        int foo = 42;
    }
    {
        Object bar = "text";
    }
    {
        long x = 100L;
    }
    {
        Object foo, bar = new Object();
    }
}

将（通常）编译为

  public static void example();
    Code:
       0: bipush        42
       2: istore_0
       3: ldc           #1                  // String text
       5: astore_0
       6: ldc2_w        #2                  // long 100l
       9: lstore_0
      10: new           #4                  // class java/lang/Object
      13: dup
      14: invokespecial #5                  // Method java/lang/Object."<init>":()V
      17: astore_1
      18: return

0请注意堆栈帧中索引处的局部变量如何使用不同类型的值重新分配。作为奖励，最后存储到变量索引1会使索引处的变量无效，0否则它将包含一个悬空的一半long值。

没有关于局部变量类型的额外提示，调试信息是可选的，并且堆栈映射表仅在代码包含分支时才存在。

确定局部变量是否包含引用的唯一方法是遵循程序流程并追溯指令的效果。这确实意味着推断操作数堆栈上的值，因为没有它，我们甚至不知道store指令放入变量的内容。

验证器会这样做，甚至是强制性的，垃圾收集器或 JVM 的任何支持代码也可以这样做。一个实现甚至可以有一个分析代码来保存第一次分析的类型信息，这将是验证。

但是，即使每次垃圾收集器需要这些信息时都重新构建这些信息，开销也不会是天文数字。垃圾收集器只定期运行，它只需要当前执行的方法的这些信息。这只是关于解释执行的全部内容。

当 JIT 编译器生成代码时，它无论如何都需要利用类型信息，并且可以为垃圾收集器准备信息，但它只会在称为安全点的某些点上这样做，在这些点上，生成的代码会检查是否存在未完成的垃圾收集。这意味着在这些点之间，数据不需要采用垃圾收集器可以理解的形式，并且优化的代码可以假设垃圾收集器在处理对象时不会重新定位对象。

这也意味着在编译的、优化的代码中，可达性可能与简单的解释执行中完全不同，即可能不存在未使用的变量，但即使是从源代码的角度来看正在使用的对象，当优化的代码使用时也可能被认为是未使用的它们的字段的副本，例如在 CPU 寄存器中。

推荐阅读