JVMのコンパイラは「ワイド」gotoを使用しますか？

gotoJava言語では予約済みのキーワードですが、実際には使用されていません。そして、あなたはおそらくそれgotoがJava仮想マシン（JVM）オペコードであることも知っています。私は、Java、ScalaのとKotlinのすべての高度な制御フロー構造は、JVMレベルで、いくつかの組み合わせを使用して実装されて数えるgotoとifeq、ifle、ifltなど、

JVM仕様https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.goto_wを見ると、goto_wオペコードもあることがわかります。一方、gotoオフセット2バイトの分岐を取り、goto_wオフセット4バイトの分岐を取ります。仕様には、

がgoto_w命令はオフセット4バイトの分岐を取り、他の要因は、65535バイト（§4.11）のメソッドのサイズを制限します。この制限は、Java仮想マシンの将来のリリースで引き上げられる可能性があります。

goto_w他のいくつかの*_wオペコードのように、将来に備えているように思えます。しかし、私goto_wはgoto、必要に応じて調整を行って、上位2バイトをゼロにし、下位2バイトをと同じように使用して、必要に応じて調整することもできます。

たとえば、次のJava Switch-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の制限で使用できる理由があるかどうか、それが実行できることを示すこと以外にあるのかどうかです。

メソッドコードのサイズは、最大64Kです。

shortのブランチオフセットは、goto-32768〜32767の符号付き16ビット整数です。

したがって、短いオフセットでは、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
          ...

goto_wブランチがに収まる場合に使用する理由はありませんgoto。しかし、ブランチも後方に移動する可能性があるため、符号付きオフセットを使用して、ブランチが相対パスであることを見逃しているようです。

のようなツールの出力を見ても気づかないでしょう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
…

一部のコンパイラー（1.6.0および11.0.7で試行）では、メソッドが十分に大きく、goto_wが必要な場合は、goto_w のみを使用するようです。非常にローカルなジャンプがある場合でも、goto_wを使用します。