JVM エスケープ解析

[[334435]]

エスケープ分析とは何か

コンパイラの最適化理論では、エスケープ解析はポインタの動的範囲を決定する方法であり、プログラム内のどこでポインタにアクセスできるかを解析します。ポインタ分析と形状分析が含まれます。

変数 (またはオブジェクト) がサブルーチン内に割り当てられると、その変数へのポインターが他の実行スレッドに逃げたり、呼び出し元のサブルーチンに返されたりすることがあります。末尾再帰最適化が使用されている場合 (関数型プログラミング言語では多くの場合望ましい)、オブジェクトは呼び出されたサブルーチンにエスケープすることも考えられます。言語がファーストクラスの継続をサポートしている場合 (Scheme や Standard ML of New Jersey など)、呼び出しスタックの一部がエスケープされる可能性があります。

ルーチンがオブジェクトを割り当て、そのオブジェクトへのポインターを返す場合、オブジェクトはプログラム内の未確定のポイントからアクセスされる可能性があります。つまり、ポインターは正常に「エスケープ」されます。ポインターがグローバル変数またはその他のデータ構造に格納されている場合、グローバル変数は現在のサブルーチンの外部からアクセスできるため、ポインターもエスケープされます。

エスケープ分析では、ポインターを格納できるすべての場所と、ポインターの有効期間が現在のプロセスまたは他のスレッドに制限されるかどうかが決定されます。

Java でのエスケープ分析がどのようなものか見てみましょう。

Java エスケープ解析は JIT コンパイルでのみ実行されます。初期の静的コンパイルで実行しないのはなぜですか?知乎にそのような質問がありました。

一言で言えば、はい、可能です。ただし、Java の個別のコンパイルと動的ロードにより、初期の静的コンパイル エスケープ分析が困難になったり、利益が低下したりします。したがって、Java エスケープ解析は現在 JIT コンパイルでのみ実行されます。十分な実行データを収集することで、JVM はオブジェクトが脱出したかどうかをより正確に判断できます。 JIT ジャストインタイム コンパイルの詳細については、「JVM シリーズ: JIT の概要」を参照してください。

JVM が新しく作成されたオブジェクトがエスケープされるかどうかを判断する基準は次のとおりです。

1. オブジェクトは、ヒープ内のオブジェクトのフィールドとクラスの静的変数に割り当てられます。

次に、オブジェクトは不確実なコードに渡されて実行されます。

上記の条件のいずれかが満たされた場合、JVM はオブジェクトがエスケープしたと判断します。最初のケースでは、オブジェクトがヒープ内に配置されているため、他のスレッドがアクセスでき、コンパイラはオブジェクトの使用状況を追跡できなくなります。 2 番目の状況は、JVM が通常のバイトコードを解析している場合と同じです。 JIT コンパイルが行われない場合、コンパイラはこのコードがオブジェクトに対してどのような操作を実行するかを事前に完全に知ることができません。保守的に考えると、現時点ではオブジェクトをエスケープとしてのみ扱うことができます。いくつか例を挙げます

パブリッククラスEscapeTest { 
 
公共 静的オブジェクト globalVariableObject; 
 
パブリックオブジェクト インスタンス オブジェクト; 
 
パブリックvoid globalVariableEscape(){
        グローバル変数オブジェクト = 新しいオブジェクト(); //静的変数、外部スレッドから参照可能、エスケープ発生
    } 
 
パブリックvoid インスタンスオブジェクトエスケープ(){
        インスタンスオブジェクト = 新しいオブジェクト(); //ヒープ内のインスタンス フィールドに代入し、外部スレッドから参照可能、エスケープ発生
    } 
     
パブリックオブジェクト returnObjectEscape(){
新しいオブジェクト()を返します。 //インスタンスを返す。外部スレッドから見えるが、エスケープが発生する
    } 
 
パブリックvoid noEscape(){
        同期された（新しいオブジェクト（））{
            // 作成スレッドにのみ表示され、オブジェクトにはエスケープがありません
        }
        オブジェクト noEscape = 新しいオブジェクト(); // 作成スレッドにのみ表示され、オブジェクトにはエスケープがありません
    } 
 
 }

エスケープ解析に基づく最適化

オブジェクトがエスケープしていないと判断された場合、コンパイラはエスケープ分析の結果を使用してコードの最適化を実行できます。

ヒープ割り当てをスタック割り当てに変換します。オブジェクトがサブルーチン内に割り当てられ、オブジェクトへのポインタが決してエスケープしない場合は、オブジェクトをヒープではなくスタックに割り当てることができます。ガベージ コレクションを備えた言語では、この最適化によりガベージ コレクターが実行される頻度を減らすことができます。

同期除去。オブジェクトが 1 つのスレッドからのみアクセス可能であることが判明した場合、このオブジェクトに対する操作を同期する必要はありません。

オブジェクトまたはスカラー置換を切り離します。オブジェクトのアクセス方法でオブジェクトが連続したメモリ構造である必要がない場合は、オブジェクトの一部 (またはすべて) をメモリではなく CPU レジスタに格納できます。

最適化 1 については、ヒープ割り当てをスタック割り当てに変換するという最適化も理解しやすいです。次のコード例はこれを示しています。

仮想マシン構成パラメータ: -XX:+PrintGC -Xms5M -Xmn5M -XX:+DoEscapeAnalysis

• -XX:+DoEscapeAnalysis はエスケープ解析を有効にすることを意味します。これは JDK8 ではデフォルトで有効になっています。
• -XX:+PrintGCはGC情報を印刷することを意味します
• -Xms5M -Xmn5M JVMメモリサイズを5Mに設定する

公共 静的void main(String[] args){
 ( int i = 0; i < 5_000_000; i++) {
            オブジェクトを作成します。
        }
    } 
 
公共 静的void createObject(){
        新しいオブジェクト();
    }

操作の結果、GC は発生しません。

仮想マシンのパラメータを -XX:+PrintGC -Xms5M -Xmn5M -XX:-DoEscapeAnalysis に変更します。以下は、エスケープ分析を無効にした後の結果の部分的なスクリーンショットです。GC がかなり頻繁に実行されたことがわかります。

 [GC (割り当て失敗) 4096K->504K(5632K)、0.0012864 秒]
 [GC (割り当て失敗) 4600K->456K(5632K)、0.0008329 秒]
 [GC (割り当て失敗) 4552K->424K(5632K)、0.0006392 秒]
 [GC (割り当て失敗) 4520K->440K(5632K)、0.0007061 秒]
 [GC (割り当て失敗) 4536K->456K(5632K)、0.0009787 秒]
 [GC (割り当て失敗) 4552K->440K(5632K)、0.0007206 秒]
 [GC (割り当て失敗) 4536K->520K(5632K)、0.0009295秒]
 [GC (割り当て失敗) 4616K->512K(4608K)、0.0005874 秒]

これは、エスケープ解析の後、JVM が createObject() メソッド スタックにオブジェクトを割り当てたことを示しています。メソッド スタック上のメソッドが実行されると、スタック フレームがポップされ、オブジェクトが自動的にリサイクルされます。この方法では、メモリのリサイクルをトリガーするためにメモリがいっぱいになるまで待つ必要はありません。これの利点は、プログラムメモリの回復効率が高く、GC 頻度も減少し、プログラムのパフォーマンスが向上することです。

2番目の同期ロックの除去を最適化する

オブジェクトが 1 つのスレッドからのみアクセス可能であることが判明した場合、このオブジェクトに対する操作を同期する必要はありません。

仮想マシン構成パラメータ: -XX:+PrintGC -Xms500M -Xmn500M -XX:+DoEscapeAnalysis。 500M を設定すると、GC がトリガーされなくなります。

公共 静的void main(String[] args){
        長い開始 = System.currentTimeMillis();
 ( int i = 0; i < 5_000_000; i++) {
            オブジェクトを作成します。
        }
        システム。出力.println( "cost = " + (System.currentTimeMillis() - start) + "ms" );
    } 
 
公共 静的void createObject(){
        同期された（新しいオブジェクト（））{ 
 
        }
    }

運用結果

コスト = 6ms

エスケープ分析をオフにする: -XX:+PrintGC -Xms500M -Xmn500M -XX:-DoEscapeAnalysis

運用結果

コスト = 270ms

エスケープ解析によってロックが排除され、パフォーマンスが大幅に向上することがわかります。ここでは、JIT のジャストインタイムコンパイルがメソッドレベルで行われるため、Java のエスケープ解析はメソッドレベルで行われることを説明したいと思います。

利点 3: オブジェクトまたはスカラーの置き換えを分離します。

簡単に言えば、オブジェクトを基本型に分解し、ヒープではなくスタックにメモリを割り当てることを意味します。これの利点は次のとおりです。1. オブジェクト ヘッダーを生成する必要がないため、メモリ使用量が削減されます。第二に、プログラムメモリの回復効率が高く、GC 頻度も削減されます。一般的に言えば、その効果は上記の利点と同様です。

さて、これで、JVM が舞台裏で行っているもう 1 つの賢い処理がわかりました。