try-with-resourcesのコンパイルと逆コンパイル、またはバグの修正方法とその原因についてのストーリー。

はじめに

しばらく前に、ワーキングドラフトのバックログはほとんど空であり、さまざまな研究タスクが浮上しました。 それらの1つは非常に興味深そうに聞こえました： PITestを使用してプロジェクトに突然変異テストを固定すること 。 Habréには、すでにこのライブラリの非常に詳細な概要があります（例と写真付き）。 私はこの記事を私自身の言葉で語るつもりはありませんが、それでも前もってそれを理解することをお勧めします。

突然変異テストのアイデアが生まれたことは認めます。 余分な労力をほとんどかけることなく、コード内の潜在的に危険な場所を見つけるためのツールを入手する価値があります！ 遅滞なく仕事に取りかかりました。 当時、ライブラリは比較的若く、その結果、非常に粗雑なものでした。ここでは、Mavenの設定で少し遊ぶ必要があります。そこで、Sonarのプラグインにパッチを当てます。 しかし、しばらくして、プロジェクト全体をチェックアウトすることができました。 結果：数百の生き残った突然変異！ ビルドサーバーでの進化をスケールします。

袖をまくり、仕事に突入しました。 一部のテストでは、スタブの十分な検証が行われませんが、他のテストでは、ロジックの代わりに、一般にテスト対象が明確ではありません。 編集、改善、書き換え。 一般に、プロセスは始まりましたが、生き残った突然変異の数は私たちが望むほど急速に減少しませんでした。 理由は簡単でした。PITは、 try-with-resourcesブロックで膨大な数の誤検知を与えました。 短い検索で、このバグは既知ですが、まだ修正されていないことが示されました。 さて、ライブラリコードは公開されています。 なぜ彼を説得し、問題が何であるかを見てみませんか？

私たちはその理由を理解しています

最も単純な例である単体テストを投げて、PITestを実行しました。 結果はあなたの前にあります。1つではなく、生き残った突然変異が11個あり、そのうち10個が「}」記号のある行を指しています。 closeおよびaddSupressedメソッドの呼び出しは、この行にtry-with-resourcesブロック用に生成されたコードが含まれることを示唆しています。 この推測を確認するために、クラスファイルを逆コンパイルすることにしました。 これを行うには、 JD-GUIを使用しましたが、 IntelliJ IDEA 14組み込みの逆コンパイラーをお勧めします。

public static void main(String[] args) throws IOException { ByteArrayOutputStream baos = new ByteArrayOutputStream(); Throwable var2 = null; try { baos.flush(); } catch (Throwable var11) { var2 = var11; throw var11; } finally { if (baos != null) { if (var2 != null) { try { baos.close(); } catch (Throwable var10) { var2.addSuppressed(var10); } } else { baos.close(); } } } } 

推測は確認されましたが、疑問が残りました。2つのtry-with-resources行がどのようにして12個のtry-catch-finally行になったのでしょうか？ gvsmirnov は、 OpenJDKソースをダウンロードするために、理解できない状況で私たちに遺贈されました。 これは私がやったことです。

try-with-resourcesコンパイルタスクに関連するすべてのコードは、 Lowerクラスの1428行と1580行の間にあります。 Javadocは、このクラスは構文糖を翻訳するように設計されていることを示しています。魔法ではなく、構文ツリーの最も単純な変更のみです。 すべてがJLS 14.20.3に準拠しています。

コンパイラの動作を把握しました。 ライブラリーがコンパイラーによって生成されたコードを変更しようとしている理由とその動作方法を理解することは残っています。 ソースを調べてみると、次のことがわかりました。 PITestは、RAMにロードされたバイトコードのみを操作します。 特定のルールに従って命令を置き換え、単体テストを実行します。 バイトコードでの作業にはASMが使用されます。

最初のアイデアは、MethodVisitorクラスのvisitGeneratedTryCatchBlockメソッドから行番号をインターセプトし、ライブラリに無視する行を指示することでした。 finallyブロックには、同様の機能がすでに実装されています。 しかし、visitGeneratedTryCatchBlockメソッドが存在しないことを知って驚いた。 ASMは、コンパイラーによって生成されたコードとプログラマーによって生成されたコードを区別しません。 待ち伏せ。 バイトコードを調べる必要がありました。その出力とフォーマットはTextifierによって親切に提供されました 。


try-catch-finallyブロックがJVMレベルで実装されるという単純な仮定は確認されていません 。 特別な指示はなく、例外テーブルとラベル間のジャンプのみがあります。 標準では、生成されたブロックを認識することが機能しないことがわかります。 別のソリューションを探す必要があります。

もしも...

コーヒーかすを推測する前に、逆コンパイルされたクラスにバイトコードマークを付けることにしました。 これがその結果です。

 public static void main(String[] args) throws IOException { ByteArrayOutputStream baos = new ByteArrayOutputStream(); // L11 Throwable primaryExc = null; // L12 try { baos.flush(); // L3 } catch (Throwable t) { // L5 primaryExc = t; throw t; } finally { // L6 if (baos != null) { // L4 L10 if (primaryExc != null) { try { baos.close(); // L0 L7 } catch (Throwable suppressedExc) { // L2 L9 primaryExc.addSuppressed(suppressedExc); // L15 L19 } // L1 L16 L8 L20 } else { baos.close(); // L14 L18 } } // L17 } // L13 } 

プログラム実行の2つの主な方法が明らかになっています。

 L11 L12 L3 {L4 [L0（L2 L15 L16）L1] L14} L13
 L11 L12 L3 [L5 {L6] L10 [L7（L9 L19 L20）L8] L18 L17}

互いの下には、コードブロックが一致またはほぼ一致するラベルがあります。 括弧内は、 closeメソッドが例外をスローしたときに実行されるコードです。 同様に正方形で- フラッシュメソッドの場合。 finallyブロックがコンパイラによって2回置換されたため、2つの方法が判明しました。 さて、視覚パーサーを完全に壊すために、中括弧内のラベルは11行目を参照しています。PITestの誤検知は同じ行を参照しています。

これが解決策です！ 最小限の繰り返し命令セットを強調表示する必要があります。 そのようなセットがテスト対象のバイトコードで見つかった場合、さらには1行で見つかった場合は、try-with-resourcesブロック用に生成されたコードが利用可能です。 それほど難しい音ではありませんが、試してみることにしました。 以下は、私が最終的に行った指示のリストです。

 private static final List<Integer> JAVAC_CLASS_INS_SEQUENCE = Arrays.asList( ASTORE, // store throwable ALOAD, IFNULL, // closeable != null ALOAD, IFNULL, // localThrowable2 != null ALOAD, INVOKEVIRTUAL, GOTO, // closeable.close() ASTORE, // Throwable x2 ALOAD, ALOAD, INVOKEVIRTUAL, GOTO, // localThrowable2.addSuppressed(x2) ALOAD, INVOKEVIRTUAL, // closeable.close() ALOAD, ATHROW); // throw throwable 

このようなものは、finallyブロックのコードにマップできます。

 } finally { if (closeable != null) { // IFNULL if (localThrowable2 != null) { // IFNULL try { closeable.close(); // INVOKEVIRTUAL or INVOKEINTERFACE } catch (Throwable x2) { localThrowable2.addSuppressed(x2); // INVOKEVIRTUAL } } else { closeable.close(); // INVOKEVIRTUAL or INVOKEINTERFACE } } } // ATHROW 

「そんなに難しくない」と私は数日間のハードワークの後に考えました。 さらにいくつかの例を投げました。 それらを使用するテストを作成しました。 すべてがうまくいき、すべてが機能します。 PITestをビルドして、ライブコードで実行しようとしました。テストは失敗しました。 私が書いたものではありません。 その他。

コンパイラは異なります

そのため、コードは「コンパイルしない」ステージから「動作しない」ステージに移動しました。 これが落ちる前に存在したテストの1つ。 ロールバック-それは動作します。 テスト内で、プロジェクトに既に存在していたJava7TryWithResources.class.binファイルがチェックされます。 バイトコードを印刷したので、私は信じられませんでした。try-with-resourcesをコンパイルするために、まったく異なる順序の命令が使用されました。

パニックにならないように、手元にあるすべてのコンパイラをチェックし始めました。 Oracle JDKのjavacで作業しましたが、OpenJDKのjavacでも同様の結果が得られました。 私はさまざまなバージョンを試しました：無駄に。 手元になかったのはコンパイラーの転換でした。 Java用のEclipseコンパイラ、ECJ。 コンパイルされ、印刷されたバイトコード-一見すると、私が探しているもののように見えます。


その後、結果のクラスファイルを逆コンパイルすることにしました。 デコンパイラの結果は、コンパイルバックを拒否しました。 まあ、何も、あなたはすでにこれで作業することができます。 バイトコードに従ってプログラムコードを持ってくる手、私は以下を得ました。

 public static void main(String[] paramArrayOfString) throws Throwable { Throwable primaryExceptionVariable = null; // L5 Throwable caughtThrowableVariable = null; try { ByteArrayOutputStream baos = new ByteArrayOutputStream(); // L3 try { baos.flush(); // L0 } catch (Throwable t) { primaryExceptionVariable = t; // L2 throw primaryExceptionVariable; // L7 } finally { if (baos != null) { // L1 baos.close(); } } } catch (Throwable t) { caughtThrowableVariable = t; // L4 if (primaryExceptionVariable == null) { primaryExceptionVariable = caughtThrowableVariable; } else if (primaryExceptionVariable != caughtThrowableVariable) { // L8 primaryExceptionVariable.addSuppressed(caughtThrowableVariable); } throw primaryExceptionVariable; // L9 } // L6 } 

ECJは、try-with-resourcesをコンパイルするためにまったく異なるアプローチを取ります。 ラベルは著しく小さく、コードのブロックは著しく大きくなります。 肥大化したテーブルの代わりに、例外は単純に次のレベルにスローされます。 より複雑な例では、入れ子人形のようなものであることがわかります。

ボンネットの下には何がありますか？ ソースをダウンロードしに行きました。今回はECJです。 tryステートメントのコンパイルは、 TryStatementファイルに隠されています。 今回は、ツリーはなく、オペコードのみ、ハードコアのみです。 try-with-resourcesの責任を負うバイトコードは、500行目と604行目に生成されます。コミットの履歴から、 tryブロックの本体は、リソースを作成および閉じるための一連の呼び出しによって単純に構成されていることがわかります。

なぜなら finallyブロックの置換がない場合、コードの重複はありません。 ただし、ネストのため、異なる例外に対して同じアクションが繰り返されます。 これを利用しました。 ECJの一連の指示は次のとおりです。

 private static final List<Integer> ECJ_INS_SEQUENCE = Arrays.asList( ASTORE, // store throwable2 ALOAD, IFNONNULL, // if (throwable1 == null) ALOAD, ASTORE, GOTO, // throwable1 = throwable2; ALOAD, ALOAD, IF_ACMPEQ, // if (throwable1 != throwable2) { ALOAD, ALOAD, INVOKEVIRTUAL, // throwable1.addSuppressed(throwable2) ALOAD, ATHROW); // throw throwable1 

そのため、対応するJavaコードは次のようになります。

 if (throwable1 == null) { // IFNONNULL throwable1 = throwable2; } else { if (throwable1 != throwable2) { // IF_ACMPEQ throwable1.addSuppressed(throwable2); // INVOKEVIRTUAL } } // ATHROW 

残りのコンパイラはどうですか？ AspectJがECJとほぼ同じバイトコードを生成することが判明しました。 彼にとって、別のシーケンスを発明する必要はありませんでした。 IBMからコンパイラーをダウンロードできませんでした（実際にダウンロードしたくありませんでした）。 普及率が低いため、他のコンパイラは無視されました。

結果

注意深い読者は、javacの一連の指示が1つのニュアンスを考慮していないことにすでに気付いています。 クラスメソッドとインターフェイスメソッドを呼び出すには、実際にはそれぞれINVOKEVIRTUALとINVOKEINTERFACEという異なる命令が使用されます。 上記の実装では、最初のケースのみが考慮され、2番目のケースは考慮されません。 まあ、何も、修正するのは難しくありません。

結果はどうなりますか？

まず、作業の主な結果は、記事の冒頭で言及したバグを修正するパッチでした。 ほとんどすべてのコードは1つのクラスに収まります（テストはカウントしません）。これは現在、 TryWithResourcesMethodVisitorのようになっています。 この問題を解決するための最良の選択肢を批判し、提案することを皆に勧めます。

次に、try-with-resourcesブロックをコンパイルする方法を見つけました。 その結果、try-catch-finallyがバイトコードレベルでどのように見えるかを見つけました。 さて、副産物は記事の翻訳でした。

第三に、私はあなたにすべてを言ったこの記事を書きました。 おそらく今、あなたの1人が、獲得した知識を使用して、 浪費の基本的な係数を増やすことができるでしょう。

そして、使用と道徳はどこにありますか？ 私は彼らの検索を読者に任せます。 私はこの記事を書いている間、私が楽しんだことだけに注意します。 読んでいただけたら幸いです。 じゃあね！

PSボーナスとして、Joshua Blochからのtry-with-resourcesの実装に関する初期の提案を検討することをお勧めします。

好奇心if盛な人は、元のARMブロック（試用リソース）の提案につまずきました。 V1： https : //t.co/Qngv2STN1W、V2 ： https : //t.co/YiR1RvyZWg

-ジョシュアブロッホ（@joshbloch） 2015年6月13日

面白そうです。

 { final LocalVariableDeclaration ; boolean #suppressSecondaryException = false; try Block catch (final Throwable #t) { #suppressSecondaryException = true; throw #t; } finally { if (#suppressSecondaryException) try { localVar.close(); } catch(Exception #ignore) { } else localVar.close(); } }