今日は、Oracle Java HotSpot VMに同梱されているガベージコレクターに関する一連の記事を続けます。 すでに少し理論を研究し、シリアルGCとパラレルGCの2つの基本的なコレクターがどのように対処するかを調べました。 この記事では、CMS GCコレクターとG1 GCコレクターについて説明します。CMSGCおよびG1 GCコレクターの主なタスクは、中規模および大量のデータで動作するアプリケーションのメモリ、つまりサーバーアプリケーションのメモリのほとんどの部分で順序を復元する際の一時停止を最小限に抑えることです。



これらの2つのコレクターは、一般的な名前「ほとんどの同時コレクター」 、つまり「ほとんどの場合 、 競合コレクター 」の 下で結合されます。 これは、アプリケーションのメインスレッドと並行して作業の一部を実行する、つまり、ある時点でプロセッサリソースを求めて競合するという事実によるものです。 もちろん、これはトレースなしでは通用しないため、結果として、一時停止の観点からの改善とスループットの観点からの低下を交換します。 彼らはさまざまな方法でそれを行いますが。 方法を見てみましょう。

CMS GC

CMSコレクター（同時マークスイープの略）は、並列GCと同時にHotSpot VMに登場し、複数のプロセッサコアにアクセスし、 STWの一時停止に敏感なアプリケーションで使用するための代替として使用されました。 当時、別の選択肢がありました-インクリメンタルGCですが、明確な利点がないため、自然選択は行われませんでした。 そして、CMSは生き残りました。 そして、その人気のピークはすでに過ぎているように見えますが、その内部構造を見るのは興味深いでしょう。それに組み込まれたアイデアのいくつかは、より現代的なG1 GCに移行しました。



CMS GCの使用は、オプション-XX：+ UseConcMarkSweepGCによって有効になります。

動作原理

シーケンシャルアセンブラとパラレルアセンブラを検討する際に、マークとスイープという言葉を既に満たしました（まだ会っていない場合は、今がその時です ）。 彼らは、古い世代のガベージコレクションのプロセスに2つのステップを示しました。生き残ったオブジェクトにマークを付け、死んだオブジェクトを削除します。 CMSコレクターは、メインプログラムの操作と並行してこれらのステップを実行するという事実により、その名前を得ました。



同時に、CMS GCは、既に考慮されているシリアル/パラレルGCと同じメモリ構成を使用します。Eden+ Survivor 0 + Survivor 1 + Tenuredリージョン、および小さなガベージコレクションの同じ原則です。 違いは、組み立てを完了することから始まります。 CMSの場合、若い世代のオブジェクトに影響しないため、完全なアセンブリではなく、 メジャーアセンブリと呼ばれます。 その結果、ここの小規模アセンブリと上級アセンブリは常に分離されています。 この分離の副作用の1つは、若い世代のすべてのオブジェクト（死んでいる可能性がある場合でも）が、古い世代のオブジェクトのステータスを決定する際にルートの役割を果たすことができることです。



CMSコレクターと以前に検討されたコレクターの重要な違いは、古いビルドを開始するためにTenuredが完了するのを待たないことです。 その代わり、彼はバックグラウンドで絶えず働いており、Tenuredをコンパクトにしようとしています。



CMS GCを使用する場合、古いガベージコレクションがどのようなものか見てみましょう。



メインアプリケーションスレッドを停止し、ルートから直接アクセス可能なすべてのオブジェクトをマークすることから始まります。 その後、アプリケーションは作業を再開し、それと並行して、コレクターは非常にマークされたルートオブジェクト（この部分は1つまたは複数のスレッドで実行）からリンクによってアクセス可能なすべての生きているオブジェクトを検索します。



当然、そのような検索中に、ヒープ内の状況は変化する可能性があり、生きているオブジェクトの検索中に収集されたすべての情報が関連するわけではありません。 したがって、コレクターは再びアプリケーションを一時停止し、ヒープをスキャンして、最初のパスでそれを回避したライブオブジェクトを見つけます。 同時に、オブジェクトはライブで記録されると想定されていますが、リストが完成した時点では、そのようなものはなくなります。 これらのオブジェクトはフローティングガベージと呼ばれ、次のビルド中に削除されます。



生きているオブジェクトにマークが付けられた後、アプリケーションのメインスレッドは動作を再開し、コレクターはいくつかの並列スレッドでデッドオブジェクトのメモリを消去します。 アプリケーションの実行中にこれを行うことは非常に難しいため、クリーニング後、古い世代のオブジェクトのパッケージ化は実行されないことに注意してください。









CMSビルダーは十分にスマートです。 たとえば、彼はアプリケーションの作業で長い一時停止を作成しないように、古いガベージコレクションを適時に配布しようとします（この多様性についての追加の詳細はコメント ）。 これを行うために、彼は過去のビルドに関する統計を保持し、それに基づいて後続のビルドを計画します。



それとは別に、メモリが完全になくなる前に、コレクターがTenuredをクリアする時間がない状況を考慮する必要があります。 この場合、アプリケーションは停止し、アセンブリ全体が順次モードで実行されます。 この状況は、 同時モード障害と呼ばれます 。 -verbose：gcまたは-Xloggc：filenameオプションが有効になっている場合、コレクターはこれらのエラーについて通知します 。



CMSには、インクリメンタルモード（i-cms）と呼ばれる興味深い動作モードがあります。これにより、メインアプリケーションと並行して動作している間、一時的に停止し、プロセッサリソースを短時間（車のABSのようなもの）解放します。 これは、コアの少ないマシンで役立ちます。 ただし、このモードは使用が推奨されていないと既にマークされており、将来のリリースでは無効になる可能性があるため、詳細な分析は行いません。

STWの状況

上記のすべてから、通常のガベージコレクション中に、CMS GCは次のような状況でSTWにつながることになります。

• 小さなガベージコレクション。 この一時停止は、Parallel GCの同様の一時停止と変わりません。
• 古いビルド内の生きているオブジェクトの検索の初期フェーズ（いわゆる初期マーク一時停止 ）。 この一時停止は通常非常に短いです。
• 古いビルド内の生きているオブジェクトのセットの完了フェーズ（ 注釈ポーズとも呼ばれます）。 通常、最初の検索フェーズよりも長くなります。

競争体制が失敗した場合、一時停止は十分に長い時間遅れる場合があります。

カスタマイズ

CMSでメモリを整理する方法は、シリアル/パラレルGCで使用される方法と似ているため、ヒープ領域のサイズを決定するための同じオプションと、必要なパフォーマンスパラメータの自動チューニングオプションが適用できます。



通常、CMSは、アプリケーションの動作で収集された統計に基づいて、古いビルドを実行する必要がある時期を決定しますが、古いビルドを開始する必要がある到達時に、Tenuredリージョンのコンテンツのしきい値も持っています。 このしきい値は、 -XXオプションを使用して設定できます。CMSInitiatingOccupancyFraction=？ 、値はパーセンテージで示されます。 -1の値（デフォルトで設定される場合があります）は、この条件によってアセンブリが無効になっていることを示します。

長所と短所

以前に検討されたシリアル/パラレルGCと比較したこのビルダーの利点は、多くのアプリケーションにとって重要な要因であるダウンタイムの最小化に焦点を当てていることです。 ただし、このタスクを実行するには、プロセッサリソースと多くの場合全体のスループットを犠牲にする必要があります。



このコレクターは古い世代のオブジェクトを圧縮しないため、Tenuredの断片化につながることを思い出してください。 この事実は、フローティングガベージの存在とともに、他のコレクターに必要なメモリよりも多くのメモリ（具体的には、古い世代）を割り当てる必要につながります（Oracleは20％以上を推奨しています）。



さて、競争体制の潜在的な失敗の場合の長い休止は不快な驚きである場合もあります。 それらは頻繁ではありませんが、十分なメモリがある場合、CMSはそれらを完全に回避できます。



ただし、このようなコレクターは、長期間存続する大量のデータを使用するアプリケーションに適している場合があります。 この場合、その欠点のいくつかは平準化されています。 ただし、いずれにしても、Java HotSpot VMクリップで別のコレクターに会うまで、その使用を決定しないでください。

---

G1 GC

そこで、私たちは最後の、おそらく最も興味深いガベージコレクターの多くに到達しました-G1（これはGarbage Firstの略語です）。 主に興味深いのは、シリアル/パラレル/ CMSラインの明示的な継続ではなく、ガベージコレクションの任意のフェーズに並列性を追加するが、メモリのクリーニングタスクに大幅に異なるアプローチを使用するためです。



G1は、最も若いHotSpot仮想マシンのガベージコレクターです。 当初は、ヒープが大きい（4 GB以上）アプリケーションのコレクターとして位置付けられていました。スループットが低下したとしても、応答時間を小さく予測可能な状態に保つことが重要です。 この分野では、彼はCMS GCと競争しましたが、当初は私たちが望むほど成功していませんでした。 しかし、徐々に修正、改善、安定化され、最終的にOracleがCMSの長期的な代替としてそれを語るレベルに達し、Open JDKはバージョン9のサーバー構成のデフォルトコレクターであると真剣に考えています。



これはすべて、明らかに彼のデバイスに対処する価値があります。 延期しません。



G1はJavaオプション-XX：+ UseG1GCによって有効になります。

動作原理

G1を検討するときに最初に目を引くのは、ヒープの整理方法の変更です。 ここでは、メモリは同じサイズの多くの領域に分割されます。 これらの領域のサイズはヒープの合計サイズに依存し、デフォルトで選択されるため、2048以下、通常は1〜32 MBになります。 唯一の例外は、いわゆる巨大な領域です 。これは、非常に大きなオブジェクトを収容するために通常の領域の結合によって作成されます。



この場合のリージョンのエデン、サバイバー、およびテニュアドへの分割は論理的であり、同じ世代のリージョンは連続する必要はなく、特定の世代のメンバーシップを変更することもできます。 ヒープを領域に分割する例は次のようになります（領域の数が大幅に減少します）。









小さなアセンブリは定期的に実行され、若い世代をクリーンアップしてオブジェクトをSurvivorリージョンに転送するか、Tenuredに転送して古い世代にアップグレードします。 複数のスレッドがオブジェクトの転送で動作し、メインアプリケーションはこのプロセス中に動作を停止します。 このアプローチは、以前に検討されたコレクターからすでによく知られていますが、違いは、世代全体ではなく、コレクターが目的の時間を超えずにクリーニングできる領域の一部でのみ実行されることです。 同時に、彼は、彼の意見では、ごみの最大量が蓄積され、その清掃が最大の結果をもたらす地域を清掃するために選択します。 したがって、名前はGarbage First-そもそもゴミです。



また、完全なアセンブリ（より正確には、ここではmixedと呼ばれます ）を使用すると、以前に検討したアセンブラよりもすべてが少し複雑になります。 G1には、 マーキングサイクルと呼ばれるプロセスがあります。これは、メインアプリケーションと並行して実行され、生きているオブジェクトのリストをコンパイルします。 最後の段落を除いて、このプロセスはすでによく知られています。

1. 初期マーク。 小さなアセンブリから取得した情報を使用して、（メインアプリケーションを停止して）ルートをマークします。
2. 同時マーキング。 メインアプリケーションの操作と並行して、ヒープ上のすべての生きているオブジェクトを複数のスレッドでマークします。
3. 発言 以前にアカウントに登録されていない生きているオブジェクトの追加検索（メインアプリケーションを停止）。
4. クリーンアップ オブジェクトへのリンクのアカウンティングのための補助構造のクリーニング、および新しいオブジェクトを配置するためにすでに使用できる空の領域の検索。 このステップの最初の部分は、メインアプリケーションが停止したときに実行されます。

生きているオブジェクトのリストを取得するために、G1はスナップショット開始時（SATB）アルゴリズムを使用します。つまり、アルゴリズムが開始された時点で存在していたすべてのオブジェクトと、その間に作成されたすべてのオブジェクトが生きているオブジェクトのリストに含まれます。その実装。 これは、特に、G1が浮遊破片を許容することを意味します。これは、CMSコレクターを検討したときに出会ったものです。



タグ付けサイクルの終了後、G1は混合アセンブリの実行に切り替えます。 これは、各アセンブリで、多くの古い世代の領域が、クリーニングされる若い世代の領域のセットに追加されることを意味します。 そのようなアセンブリの数およびクリーニングされる古い領域の数は、必要なアセンブリ時間を超えないように、以前のアセンブリについてコレクタによって収集された統計に基づいて選択されます。 コレクターが十分なメモリをクリアすると、スモールアセンブリモードに戻ります。



ヒープが特定のしきい値を超えると、次のタグ付けサイクル、およびその結果、次の混合アセンブリが起動されます。



上記のヒープ例の混合ガベージコレクションは、次のようになります。









メモリクリーニングプロセス中に、存続オブジェクトをコピーできるヒープに空き領域がないことが判明する場合があります。 これは、CMSで見た類似点である割り当て（避難）失敗の状況につながります。 この場合、メインアプリケーションスレッドが停止すると、コレクターはヒープ全体で完全なガベージコレクションを実行します。



前述の以前のアセンブリの統計に基づいて、G1は特定の世代に割り当てられた領域の数を変更して、将来のアセンブリを最適化できます。

巨人

G1についての話の冒頭で、いわゆる巨大なオブジェクト（巨大なオブジェクト）が格納されている巨大な領域の存在に言及しました。 JVMの観点からは、領域の半分より大きいオブジェクトは巨大と見なされ、特別な方法で処理されます。

• リージョン間を移動することはありません。
• タグ付けサイクルの一部として、または完全なガベージコレクションとして削除できます。
• 空き領域が残っていても、巨大なオブジェクトが占める領域には誰も引っ掛かりません。

一般に、これらの項目は、広範囲に及ぶ結果をもたらす場合があります。 大きなオブジェクト、特に短命のオブジェクトは、小さなアセンブリでは削除されないため、すべてのタイプのコレクターに多大な不便をもたらす可能性がありますが、古い世代の領域で貴重なスペースを占有します（前の章で説明した加速オブジェクトを覚えていますか？）彼にとっては、数メガバイト（場合によっては500 KB）のオブジェクトでさえもすでに巨大であるという事実による悪影響。 前の記事の解説では、 Solrのこのような問題の例を示しています。



この一連の記事の続きで、これに対処する方法を説明します。

STWの状況

要約すると、G1の場合、次の場合にSTWを取得します。

1. 世代間でオブジェクトを転送するプロセス。 このような一時停止を最小限に抑えるために、G1は複数のスレッドを使用します。
2. マーキングサイクルの一部としてのルートの初期マーキングの短いフェーズ。
3. タグ付けサイクルの発言フェーズの終了時およびクリーンアップフェーズの開始時の長い一時停止。

カスタマイズ

G1コレクターの主な目標はメインアプリケーションの動作の一時停止を最小限にすることであるため、それを構成するときのメインオプションは-XX：MaxGCPauseMillis =？ ワンタイムガベージコレクションの最大許容時間を設定します。 このプロパティを設定しない場合でも、少なくともデフォルト値を確認してください。 Oracleのドキュメントでは、デフォルトのビルド時間は制限されていないと記載されていますが、実際には常にそうであるとは限りません。



オプション-XX：ParallelGCThreads =？ および-XX：ConcGCThreads =？ ガベージの収集とタグ付けサイクルの実行にそれぞれ使用されるスレッドの数を設定します。



領域サイズの自動選択に慣れていない場合は、 -XXオプションを使用して手動で設定できます。G1HeapRegionSize=？ 。 メガバイト単位で測定する場合、値は2のべき乗である必要があります。 たとえば、 -XX：G1HeapRegionSize = 16m 。



必要に応じて、ヒープを満たすためのしきい値を変更できます。このしきい値に達すると、タグ付けサイクルの実行と混合アセンブリモードへの移行が開始されます。 これは、 -XXオプションを使用して行われます。InitiatingHeapOccupancyPercent=？ 値をパーセントで取得します。 デフォルトでは、このしきい値は45％です。



G1設定の深さをさらに深くする場合は、オプション-XX：+ UnlockExperimentalVMOptionsおよび-XX：+ AggressiveOptsを使用して追加の機能を有効にし、実験的な設定を試してください。

長所と短所

一般に、G1コレクターはCMSよりも正確に一時停止サイズを予測し、特にヒープサイズが大きい場合に長いアプリケーションクラッシュを防ぐために、より適切にアセンブリを配布すると考えられています。 同時に、CMSのその他の不利な点、たとえばメモリを断片化しないなど、が奪われています。



G1の利点の代償は、メインプログラムと並行して作業のかなりの部分を実行するために使用するプロセッサリソースです。 その結果、アプリケーションの帯域幅が影響を受けます。 G1のデフォルトのターゲット帯域幅は90％です。 たとえば、並列GCの場合、この値は99％です。 もちろん、これはG1のスループットが常にほぼ10％低下することを意味するものではありませんが、この機能は常に念頭に置いておく必要があります。





そのため、HotSpot仮想マシンの4つのガベージコレクターすべての操作アルゴリズムを分析しました。 次の記事では、アプリケーションのパフォーマンスを最適化するためにこの知識をどのように適用できるかを理解しようとします。



以前：

←パート2-シリアルGCおよびパラレルGCアセンブラー

←パート1-はじめに