JVMのTry / Catch /最後にコンパイル

導入する代わりに

この記事の著者であるAlan Keefer ¹は、保険ビジネスソフトウェア会社であるGuidewire Software ^2のリードアーキテクトです。 彼はまだ上級開発者でしたが、Gosu ³言語の作業に参加しました。 特に、Alanは言語をJavaバイトコードにコンパイルする問題に対処しました。



この記事は2009年に書かれたもので、JVMバージョン1.6でのtry / catch /の実装の詳細に専念しています。 これを読むには、Java構文の基本的な知識が必要です。また、シートがカットされているバイトコードの目的を理解する必要があります。 また、この記事の最後には、SCJPのトリッキーなタスクに似た一連の例があります。

JVM内部

現在取り組んでいることの1つは、「ホーム」言語をJavaバイトコードにコンパイルすることです。 （参考：いつ終了するかは言えません。おおよそです。将来のリリースに落ちても。）おもしろいのは、JVMの内部を調べて、あなた自身の言語のすべてのクソの鋭いコーナーを見つけることです。 しかし、すべての「楽しい」と鋭いコーナーのほとんどは、try / catch / finallyなどの演算子から来ています。 したがって、今回は、哲学やアジャイルには触れません。 その代わりに、私はJVMを掘り下げます。ほとんどの場合、掘り下げる必要はありません（したくない）。



2週間前についにブロックについて尋ねられた場合、それらの処理はJVMに実装されることをお勧めします。これは言語の基本的な部分であり、組み込みである必要があります。 私が知ったときの驚きを想像してください：いいえ、そうではありません。 実際、finally-blocksは、try-または関連付けられたcatch-blocksの後に可能なすべての場所で単純に置き換えられます。 これらのブロックは「catch（Throwable）」でラップされ、finallyブロックが終了すると例外がスローされます。 残っているのは、例外テーブルをねじって、置換されたfinallyブロックがスキップされるようにすることだけです。 まあどう？ （小さな警告：JVM 1.6より前では、finallyオペレーターについては、完全な置換の代わりにサブルーチンが使用されたようです。しかし、ここでは、上記のすべてが適用されるバージョン1.6について説明しています。）



このアプローチが理にかなっているかどうかを理解するには、少し巻き戻して、JVMが例外を処理する方法を確認してください。 それらの処理は、特別なメソッドを使用してtry / catchブロックを宣言する形式でJVMに組み込まれています。 必要なことは、「ポイントAとポイントBの間、タイプEの例外はすべて、ポイントCのコードで処理する必要がある」と言うことだけです。 これらの宣言は必要な数だけ持つことができます。 このメソッドに例外が渡されると、JVMはそのタイプに応じて適切なcatchブロックを見つけます。

try / catchブロックの簡単な例

簡単な例を考えてみましょう。

public void simpleTryCatch() { try { callSomeMethod(); } catch (RuntimeException e) { handleException(e); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

彼にとっては、以下のバイトコードになります。 （JVMメカニズムを学習するための貴重なツールであるASM Eclipseが提供するフォーマットを使用しています。このフォーマットのコードは非常に読みやすいようです。「L0」などはコードラベルです。）

 public simpleTryCatch()V TRYCATCHBLOCK L0 L1 L2 java/lang/RuntimeException L0 ALOAD 0 INVOKEVIRTUAL test/SimpleTryCatch.callSomeMethod()V L1 GOTO L3 L2 ASTORE 1 ALOAD 0 ALOAD 1 INVOKEVIRTUAL test/SimpleTryCatch.handleException(Ljava/lang/RuntimeException;)V L3 RETURN
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、catchステートメントにtryブロック全体をカバーするように指示します（ただし、最後のGOTOステートメントはカバーしません）。RuntimeExceptionの場合は、L2に制御を渡します。 tryステートメントが完了したら、catchステートメントを飛び越えて実行を継続する必要があります。 RuntimeExceptionハンドラーが呼び出された場合、例外はスタックの一番上にあり、ローカル変数に保存します。 次に、「this」へのポインタと例外をその順序でロードして、handleExceptionメソッドを呼び出します。 その後、残りのコードが最後まで実行されます。 ただし、追加のcatchブロックがあれば、ジャンプしていました。

try / catch / finallyブロックの例

ここで、finallyブロックと追加のcatchステートメントを追加し、バイトコードで何が起こるかを確認します。 次の完全に不自然な例を取り上げます。

 public void tryCatchFinally(boolean arg) { try { callSomeMethod(); if (arg) { return; } callSomeMethod(); } catch (RuntimeException e) { handleException(e); } catch (Exception e) { return; } finally { callFinallyMethod(); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合、明確なバイトコードははるかに少なくなります。

 public tryCatchFinally(Z)V TRYCATCHBLOCK L0 L1 L2 java/lang/RuntimeException TRYCATCHBLOCK L3 L4 L2 java/lang/RuntimeException TRYCATCHBLOCK L0 L1 L5 java/lang/Exception TRYCATCHBLOCK L3 L4 L5 java/lang/Exception TRYCATCHBLOCK L0 L1 L6 TRYCATCHBLOCK L3 L7 L6 TRYCATCHBLOCK L5 L8 L6 L0 ALOAD 0 INVOKEVIRTUAL test/SimpleTryCatch.callSomeMethod()V L9 ILOAD 1 IFEQ L3 L1 ALOAD 0 INVOKEVIRTUAL test/SimpleTryCatch.callFinallyMethod()V L10 RETURN L3 ALOAD 0 INVOKEVIRTUAL test/SimpleTryCatch.callSomeMethod()V L4 GOTO L11 L2 ASTORE 2 L12 ALOAD 0 ALOAD 2 INVOKEVIRTUAL test/SimpleTryCatch.handleException(Ljava/lang/RuntimeException;)V L7 ALOAD 0 INVOKEVIRTUAL test/SimpleTryCatch.callFinallyMethod()V GOTO L13 L5 ASTORE 2 L8 ALOAD 0 INVOKEVIRTUAL test/SimpleTryCatch.callFinallyMethod()V RETURN L6 ASTORE 3 ALOAD 0 INVOKEVIRTUAL test/SimpleTryCatch.callFinallyMethod()V ALOAD 3 ATHROW L11 ALOAD 0 INVOKEVIRTUAL test/SimpleTryCatch.callFinallyMethod()V L13 RETURN
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで何が起こっているのでしょうか？ （ラベルには、コードに表示される順序ではなく、コンパイラによって作成された順序で番号が付けられていることに注意してください。）まず、両方の例外処理ブロックがL0からL1およびL3の2つに分割されます。 L4へ。 これは、returnステートメントにより、finallyブロックがL1とL3の間に挿入されたために発生しました。



finallyブロックからスローされた例外は、同じtryステートメントに関連付けられたcatchブロックで処理すべきではないため、対応する範囲は例外テーブルから削除されています。 例外タイプのないテーブルのレコードは、finallyブロックを参照します。 tryステートメントまたはcatchブロックからスローされたタイプの例外を処理し、置換されたfinallyブロックを無視する必要があります。 したがって、finallyブロックは、同じfinallyブロックによってスローされた例外をキャッチしません。 tryブロック内に最後に挿入されることに加えて、catch（Exception）ブロックにはreturnステートメントも含まれるため、このようなエントリが3つありました。



また、finallyブロックがコードで5回（5回）発生することにも驚かれるかもしれません。 tryブロックのreturnステートメントに対応する最初に最後に置換されたものは、L1とL3の間で発生します。 2番目のfinallyブロックはもう少しわかりにくいです。最初のcatchブロックの最後に挿入され、finallyコードの残りの部分をジャンプします。 （個人的には、ここでは次の埋め込みではなく最後に移行する必要があったと思います。）3回目は、2番目のcatchブロックのreturnステートメントの前にL8とL6の間に現れます。 例外の場合に対応するL6とL11の間のコードに4回目のfinallyブロックが表示されます：tryブロックまたはcatchブロックでスローされた未処理の例外が発生した場合、finallyブロックが実行されることを確認する必要があります。 例外は何も起こらなかったように保存され、finallyステートメントが呼び出された後、例外がロードされて再びスローされることに注意してください。 最後のfinallyブロックでは、tryブロックの終わりから制御が渡されます。



try / catchまたはtry / finallyブロックをネストしていた場合、すべてがさらに奇妙になります。 内部tryブロックのreturnステートメントでは、内部tryと外部tryの両方のfinallyブロックで置き換える必要があります。 例外テーブルは、内部のfinalによってスローされた例外が外部のcatchステートメントとfinallyステートメントによってキャッチされ、外部のfinalによってスローされた例外が誰にもキャッチされないように構成する必要があります。 今、あなたはおそらく、コンパイラがどのような状態のセットを自分自身で運ばなければならないのかを想像しようとしています。



少なくとも私にとって、JVMの作成者が、仮想マシンに埋め込むのではなく、finallyステートメントをコンパイラーに固定することをどのように決定したかを知ることは興味深いでしょう。 明らかに、コンパイラでこの作業を行うと、仮想マシンが大幅に簡素化されますが、JVM用に別の言語を作成する私たちのような人々にとっては、生活が少し難しくなります。

カスタム例

コンパイラの実装方法を理解することにより、いくつかの非標準的なケースを理解しやすくなります。 例：

 try { return "foo"; } finally { return "bar"; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

結果は「bar」になります。これは、finallyステートメントがreturnステートメントの前に置換されるためです。つまり、finallyブロックからの戻りが最初に呼び出され、tryブロックからの戻りはまったく呼び出されません。

 String value = "foo"; try { return value; } finally { value = "bar"; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

結果は「foo」になります。これは、finallyステートメントが呼び出される前にreturnステートメントの値がプッシュされ、その後で復元されて返されるためです。 （私の例ではこれを示していませんが、これはバイトコードを見ると表示されるものです。）したがって、finallyブロックの「value」の値を変更しても、returnステートメントの値はありません。 そして最後に、次のようなもの：

 while(true) { try { return "foo"; } finally { break; } } return "bar";
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

結果は「バー」になります。 私にとっても驚きでしたが、バイトコードでbreakステートメントがGOTOに過ぎないことを知っていれば、すべてが論理的です。 つまり finallyブロックが内部returnステートメントの一部として置換されると、GOTOステートメントがRETURNステートメントよりも前に呼び出され、ループが終了します。 （finallyブロック内のcontinueステートメントについても同様です。）

おわりに

C＃で行われているように、未定義のセマンティクスのため、finallyブロック内でreturn、break、continueステートメントを禁止することにしました。 （そして、私はそのような決定を下した人々から良い会社が集まったと感じています。）



誰かがこの記事が有益だと思ったら、バイトコードを生成するときに出会った他の興味深いことについていくつかメモを書くつもりです。 これらは、JVMに直接関連するほか、クロージャ、外部関数、ジェネリックなど、言語とJavaの間のさまざまな不整合に関連します。

用語集

サブルーチン=サブルーチン

ステートメント=ステートメント

置換=インライン化

例外=例外

外部機能= 拡張 = 拡張機能 = ミックスイン

参照資料

[1] devblog.guidewire.com/author/akeefer

[2] www.guidewire.com

[3] gosu-lang.org