JVM的编译器是否使用“宽”goto？

Question

我想你们大多数人都知道goto在Java语言中是一个保留的关键字，但实际上并没有被使用。你们可能也知道goto是一个Java虚拟机（JVM）操作码。我认为Java、Scala和静态编程语言的所有复杂的控制流结构都是在JVM级别上使用goto和ifeq、iphone、iflt等的某种组合来实现的。

查看JVM规范https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.goto_w我看到还有一个goto_wopcode。而goto采用2字节的分支偏移量，goto_w采用4字节的分支偏移量。说明书上说

尽管goto_w指令采用4字节的分支偏移量，但其他因素将方法的大小限制为65535字节（§4.11）。这个限制可能会在Java虚拟机的未来版本中提高。

在我看来，goto_w就像其他一些*_w操作码一样，是未来的证明。但我也想到，也许可以使用goto_w将两个更重要的字节清零，将两个不太重要的字节与goto相同，并根据需要进行调整。

例如，给定此JavaSwitch-Case（或Scala Match-Case）：

     12: lookupswitch  {
                112785: 48 // case "red"
               3027034: 76 // case "green"
              98619139: 62 // case "blue"
               default: 87
          }
      48: aload_2
      49: ldc           #17                 // String red
      51: invokevirtual #18
            // Method java/lang/String.equals:(Ljava/lang/Object;)Z
      54: ifeq          87
      57: iconst_0
      58: istore_3
      59: goto          87
      62: aload_2
      63: ldc           #19                 // String green
      65: invokevirtual #18
            // Method java/lang/String.equals:(Ljava/lang/Object;)Z
      68: ifeq          87
      71: iconst_1
      72: istore_3
      73: goto          87
      76: aload_2
      77: ldc           #20                 // String blue
      79: invokevirtual #18 
      // etc.

我们可以把它改写成

     12: lookupswitch  { 
                112785: 48
               3027034: 78
              98619139: 64
               default: 91
          }
      48: aload_2
      49: ldc           #17                 // String red
      51: invokevirtual #18
            // Method java/lang/String.equals:(Ljava/lang/Object;)Z
      54: ifeq          91 // 00 5B
      57: iconst_0
      58: istore_3
      59: goto_w        91 // 00 00 00 5B
      64: aload_2
      65: ldc           #19                 // String green
      67: invokevirtual #18
            // Method java/lang/String.equals:(Ljava/lang/Object;)Z
      70: ifeq          91
      73: iconst_1
      74: istore_3
      75: goto_w          91
      79: aload_2
      81: ldc           #20                 // String blue
      83: invokevirtual #18 
      // etc.

我还没有真正尝试过这个，因为我可能犯了一个错误，改变了“行号”来适应goto_ws。但是既然它在规范中，应该是可以做到的。

我的问题是，是否有一个原因，编译器或其他生成器的字节码可能会使用goto_w与当前65535限制，而不是表明它可以做到？

Answer 1

在一些编译器中（在1.6.0和11.0.7中尝试过），如果一个方法足够大，goto_w，它只使用goto_w。即使它有非常局部的跳转，它仍然使用goto_w。

Answer 2

当分支装入goto时，没有理由使用goto_w。但您似乎忽略了使用有符号偏移量时分支是相对的，因为分支也可以向后移动。

在查看像javap这样的工具的输出时，您不会注意到它，因为它会在打印之前计算出最终的绝对目标地址。

所以goto的范围是-327678…32767‬并不总是足以解决0…65535范围内的每个可能目标位置。

例如，以下方法在开始时将有一个goto_w指令：

public static void methodWithLargeJump(int i) {
    for(; i == 0;) {
        try {x();} finally { switch(i){ case 1: try {x();} finally { switch(i){ case 1: 
        try {x();} finally { switch(i){ case 1: try {x();} finally { switch(i){ case 1: 
        try {x();} finally { switch(i){ case 1: try {x();} finally { switch(i){ case 1: 
        try {x();} finally { switch(i){ case 1: try {x();} finally { switch(i){ case 1: 
        try {x();} finally { switch(i){ case 1: try {x();} finally { switch(i){ case 1: 
        } } } } } } } } } } } } } } } } } } } } 
    }
}
static void x() {}

Ideone上的演示

Compiled from "Main.java"
class LargeJump {
  public static void methodWithLargeJump(int);
    Code:
       0: iload_0
       1: ifeq          9
       4: goto_w        57567
…

Answer 3

方法代码的大小可以大到64K。

shortgoto的分支偏移量是一个有符号的16位整数：从-32768到32767。

因此，短偏移量不足以使65K方法从开始跳到结束。

甚至javac有时也会发出goto_w。下面是一个例子：

public class WideGoto {

    public static void main(String[] args) {
        for (int i = 0; i < 1_000_000_000; ) {
            i += 123456;
            // ... repeat 10K times ...
        }
    }
}

用javap-c反编译：

  public static void main(java.lang.String[]);
    Code:
       0: iconst_0
       1: istore_1
       2: iload_1
       3: ldc           #2
       5: if_icmplt     13
       8: goto_w        50018     // <<< Here it is! A jump to the end of the loop
          ...