JVMがオブジェクトを移動する必要があるためだと思いますが、それは正しいですか?
4 に答える
まず、ウィキペディアのガベージ コレクションの記事は本当によく読んでいます。
一般に、GC は Stop-the-World 一時停止を必要としません。(ほぼ) 一時停止のない JVM 実装があります (例: Azul Zing JVM )。JVM がガベージを収集するために STW を必要とするときはいつでも、使用しているアルゴリズムによって異なります。
Mark Sweep Compact (MSC)は、デフォルトで HotSpot で使用される一般的なアルゴリズムです。これは STW 方式で実装され、3 つのフェーズがあります。
- MARK - ライブ オブジェクト グラフをトラバースして、到達可能なオブジェクトをマークします
- SWEEP - メモリをスキャンして、マークされていないメモリを見つけます
- COMPACT - マークされたオブジェクトを再配置して空きメモリを最適化します
ヒープ内のオブジェクトを再配置する場合、JVM はこのオブジェクトへのすべての参照を修正する必要があります。再配置プロセス中、オブジェクト グラフに一貫性がないため、STW の一時停止が必要になります。
コンカレント マーク スイープ (CMS)は、HotSpot JVM の別のアルゴリズムであり、古い領域の収集に STW 一時停止を使用しません (フル コレクションとはまったく同じではありません)。
CMS は、書き込みバリア (Java ヒープに参照を書き込むたびに動作するトリガー) を利用して、MARK の並行バージョンを実装し、COMPACT を使用しません。圧縮が行われないと断片化が発生する可能性があり、バックグラウンド ガベージ コレクションの速度が十分でない場合でも、アプリケーションがブロックされる可能性があります。このような場合、CMS は STW mark-sweep-compact コレクションにフォールバックします。
MSCのインクリメンタルバリエーションであるG1もあります。HotSpot JVM の GC アルゴリズムの詳細については、私のブログを参照してください。
スループット GC を使用する場合、JVM は可能な限り多くのメモリを解放するために STW の一時停止を必要とします。最も効果的なのは、そのような一時停止だけを使用することです。
Low-pauses Collector (CMS) を使用して、アプリケーションを一時停止することなく、古い世代を同時に消去します。欠点は、古い世代が断片化することです。断片化しすぎて圧縮が必要な場合は、フル GC (STW) が発生します。ただし、完全な GC を取得しないように、いつでもアプリケーションを調整できます。
G1 GC は特殊なケースです。現在の主な目標は、(CMS のように) 並行性を保ちながら、ヒープの断片化を少なくすることです。この目標に到達できない場合、JVM も STW 一時停止に戻り、ヒープが完全にクリーンアップされて圧縮されます。
stop-the-world は、コレクターの実行中に新しいオブジェクトが割り当てられず、オブジェクトが突然到達不能にならないようにすることを保証します。
利点は、実装が簡単で、インクリメンタル ガベージ コレクションよりも高速であることです。