48

インストルメンテーションを使用して JDK7 でコンパイルされたコードには、既知の互換性の問題があります。http://www.oracle.com/technetwork/java/javase/compatibility-417013.htmlについては

バージョン番号 51 のクラスファイルは、型チェック検証ツールを使用して排他的に検証されるため、メソッドには必要に応じて StackMapTable 属性が必要です。バージョン 50 のクラスファイルの場合、ファイル内のスタックマップが見つからないか正しくない場合、Hotspot JVM は型推論ベリファイアにフェイルオーバーします (そして、フェイルオーバーし続けます)。このフェイルオーバー動作は、バージョン 51 (Java SE 7 のデフォルト バージョン) のクラスファイルでは発生しません。バージョン 51 クラスファイルのバイトコードを変更するツールは、検証に合格するために、バイトコードと一致するようにスタックマップ情報を更新する必要があります。

解決策は、 https-XX:-UseSplitVerifier ://community.oracle.com/blogs/fabriziogiudici/2012/05/07/understanding-subtle-new-behaviours-jdk-7 に要約されているとおり に使用することです

どのくらい安全ですか？オラクルは何らかの理由でこのチェックを入れていると思います。使用しないと、他の問題が発生する可能性があります。

を使用すると、どのような結果になる可能性があり-XX:-UseSplitVerifierますか?

ありがとう、

ピーター。

4

3 に答える 3

24

はい、安全です。Judebert が言うように、クラスの読み込みがわずかに遅くなるだけです。

もう少し情報を追加するには: StackMap テーブルとは正確には何ですか? バイトコード検証ツールは、適切なタイプのデータが渡されて使用されていることを検証するために、クラス ファイル内のコードに対して 2 つのパスを作成する必要があります。低速の最初のパスでは、すべてのコードの分岐のフロー分析を行い、各バイトコード命令でスタック上にある可能性のあるデータのタイプを確認します。2 番目のパスでは、各命令を調べて、それらすべての型で有効に動作できるかどうかを確認します。

重要な点は次のとおりです。コンパイラは、最初のパスが生成するすべての情報を手元に持っているため、(Java 6 & 7 では) クラス ファイルの StackMap テーブルに格納します。

これにより、クラス ローダーが最初のパスを実行する必要がないため、クラスの読み込みが高速化されます。そのため、Split Verifier と呼ばれます。これは、作業がコンパイラとランタイム ローディング メカニズムの間で分割されるためです。-XX:-UseSplitVerifier オプションを使用すると、クラスのロード時に両方のパスを実行する (および StackMap テーブルを無視する) ように Java に指示します。多くの製品 (読み込み時にバイトコードを変更するプロファイラーなど) は、最初は StackMap テーブルを認識していなかったため、読み込み時にクラスを変更すると、コンパイラーからの StackMap テーブルが古くなり、エラーが発生しました。

要約すると、 -XX:-UseSplitVerifier オプションはクラスのロードを遅くします。セキュリティ、実行時のパフォーマンス、または機能には影響しません。

于 2013-10-15T14:13:44.387 に答える
13

Stack Map Frames は Java 7 で追加されました。「prashant」は、このアイデアには欠陥があると主張し、開発者は常に-XX:-UseSplitVerifierフラグを使用してそれらを使用しないようにすることを提案しています。

続きを読む: Java 7 Bytecode Verifier: JVM の大きな後退

于 2013-03-26T13:14:05.560 に答える