GCと大きなヒープ：友人か敵か？

どちらが優れているかという論争：科学技術の多くの分野で、手動制御または自動制御が行われています。 人に頼るか、無力なメカニズムとアルゴリズムに身を任せますか？ それにもかかわらず、エンタープライズソリューションを作成する世界では、主にポインターの混乱、手動のメモリ管理、および「不正な」コンパイラが原因で発生した各バグの後に白髪を埋めるために、スケールは自動メモリ管理に傾いているようです誰も今C / C ++を望んでいません。 しかし、フォーラムでは依然としてトピックが発生します。そこでは、人類の進歩的な部分との戦いにおいて、手動のメモリ管理の厳格な支持者を激しくかつ容赦なく放棄することはありません。 それらを放っておいてください。



自動メモリ管理メカニズムで最も一般的に使用されるプラットフォームの1つはJavaです。 しかし、自動メモリ管理は、プログラマのハードワークに快適さをもたらしただけでなく、より頻繁に直面しなければならないその欠点ももたらしました。 膨大な数のトランザクションを処理できる最新のマルチユーザーアプリケーションには、かなりのハードウェアリソースが必要であり、そのサイズはこれまで想像することすら困難でした。 ただし、問題はこれらのリソースのサイズではなく、事実、ほとんどの最新のJVMに存在するガベージコレクターは、大量のメモリで効率的に動作できないということです。



ガベージコレクターはメモリをクリアするプロセスを自動化し、プログラマーの多くの頭痛の種を取り除き、代わりに1つの大きな問題を導入します-どのGCメカニズムを使用し、どのヒープサイズが最適か？ 必要以上にヒープを作成し、一定の「世界停止」の一時停止に陥った場合、必要以上に作成しないと、「メモリ不足」エラーが表示されます。 これはすべて、ヒープのサイズが大きくなると、ガベージコレクターがメモリをクリアしてデフラグするのに時間がかかるという事実によって複雑になります。 これにより、2〜4GBを超えるヒープを使用する場合、ビジネスにとって一時停止が重要になり、数秒または数分かかることがあります。その間、メモリクリーニングプロセスが完了するまですべてのスレッドが強制的に待機します。 応答時間が長くなり、不安定になり、スループットが低下します。大規模なWebポータル、電子商取引または重要なビジネスクリティカルなアプリケーションの分野で働く企業では、これは受け入れられません。



大きなサイズのヒープaに対処するには、いくつかの方法があります。そのうちの1つは、数十または数百のインスタンスをデプロイしたり、ヒープaエリア外にデータを保存したりすることです。 この記事ではそれらに触れたくないので、今後の議論のために残しておきます。 これらのメソッドは、それらを実現するために必要な開発者と管理者の多くの作業を意味するため、非常に高価です。 私たちは、JVMのフレームワーク内に留まり、「時間」や神経、お金が費やされるサポートのための「苦労」や回避策を思いつきません。



一般的なJVMのGCにはいくつかの動作モードがあり、それらのいくつかは、すべてのスレッドが停止するいわゆる「世界停止」の一時停止を短縮するように特別に設計されていることは周知の事実です。 それでも、技術的な理由でこれらの一時停止を除外することはできませんが、1つ例外があります。これについては以下で説明します。 つまり、最良の場合でも、GCがメモリのクリアを完了するまでスレッドは待機する必要があります。 ますます受け入れられなくなることが多く、ビジネスは待つことができません。



この記事では、最も一般的なJVMの概要を簡単に説明するとともに、これらのJVMが大きなヒープを持つGCを効果的に機能させるために提供するメソッドについて説明します。 リソースの訪問者はJVMのヒープの概念に精通しており、それが何であるかを知っていると思います。 オブジェクトの生成について説明することにも意味がありません。若い世代に属するオブジェクトは、多くの場合到達不能になり、メモリから削除されると想定されることに注意してください。 ヒープの描画を行います：







作業でGCを使用する主なアルゴリズム：



マークスイープコンパクト



「マーク」：未使用のオブジェクトをマークします。



スイープ：これらのオブジェクトはメモリから削除されます。



「コンパクト」：オブジェクトは「コンパクト」で、空きスロットを占有します。これにより、「大きな」オブジェクトを作成する必要がある場合にスペースが解放されます。



3つのステップすべてを通して、「世界を停止」する一時停止があります。



コピーコレクター



「from」および「to」領域を使用して、1つのパスで3つすべてのアクションを実行します。 これは次のように発生します。作業の開始時に、サバイバースペースの1つである「To」は空で、もう1つの「From」には以前のアセンブリを生き残ったオブジェクトが含まれます。 ガベージコレクターは、Edenで生きているオブジェクトを検索してToスペースにコピーし、生きている「若い」（つまり、指定された数のガベージコレクションを残していない人）をFromスペースからコピーします。 宇宙からの古いオブジェクトは、古い世代に移動します。 アセンブリ、From spaceおよびTo space変更ロールの後、Edenエリアは空になり、Old世代のオブジェクトの数が増加します。 生きているオブジェクトToのコピー中にスペースがいっぱいになると、生き残ったガベージコレクションの数に関係なく、Toスペースに十分なスペースがなかったEdenおよびFromスペースの残りの生きているオブジェクトがOld世代に移動します。



このアルゴリズムを使用するため、ガベージコレクターはすべての生きているオブジェクトをあるメモリ領域から別のメモリ領域にコピーするだけなので、このようなガベージコレクターはコピーと呼ばれます。 明らかに、コピーガベージコレクターが機能するためには、アプリケーションには常にライブオブジェクトがコピーされる空きメモリ領域が必要です。このようなアルゴリズムは、アプリケーションメモリの合計サイズに対して比較的小さいメモリ領域に使用できます。



既存のGCの主な欠点は、一時停止の必要性です。 これらの一時停止は、メモリの断片化による避けられないイベントの結果です。 いわゆる「ほぼ同時」（ほとんどの場合同時）ガベージコレクションアルゴリズムを使用しても、遅かれ早かれ、古い世代に属する領域が非常に断片化され、新しいオブジェクトのメモリ量が不十分になるという事実に遭遇します、「mark-sweep-compact」アルゴリズムの呼び出しにつながり、アプリケーションを停止します（このイベントを時間内に遅らせる方法がもう1つあります。これについては後で詳しく説明します）。 「世界を止める」一時停止を引き起こす別のタスクは、ラベル付けです。 ほとんどの並行GCは、2つの段階で生きているオブジェクトをマークします-最初の段階は、スレッドの動作と同時にマークを含み、並行マークと呼ばれます。 2番目の段階は再ラベル付け（注釈）です。最初の段階が過ぎたときに、アプリケーションがリンクを変更したり、新しいオブジェクトを作成したりする可能性があるため、これを確認する必要があります。 この時点で、GCは「世界を停止する」一時停止を設定し、何が変更されたかをチェックします。 このアプローチにより、少数の突然変異で「世界を停止する」ポーズの合計時間を短縮できますが、多数のオブジェクトが絶えず作成および変更されている場合はあまり役に立ちません。



ここでは、最も一般的なGCの表を示します。



「モノリシック」は、世代全体が通路で浄化されなければならないことを意味します。



「ほとんどの場合、同時」-ほとんどは同時で、同時とは、「アプリケーションスレッドの操作」という背景を指します。

Java仮想マシン	コレクター名	若い世代	旧世代
Oracle HotSpot	ParallelGC	モノリシック、世界を止め、コピー	モノリシック、ストップザワールド、マーク/スイープ/コンパクト
Oracle HotSpot	CMS	モノリシック、世界を止め、コピー	ほとんどの場合、「圧縮」を伴わない同時デフラグにより​​、世界が停止します。
Oracle HotSpot	G1（ガベージファースト）	モノリシック、世界を止め、コピー	ほとんどの場合、デフラグ中に人気に基づく地域の「圧縮」と同時に、世界を停止させます
Oracle JRockit	動的なガベージコレクター	モノリシック、ストップ・ザ・ワールド、コピー	最適化の際に人気を基準にしたリージョンの「圧縮」を伴う同時または並行のマーク/スイープにより、世界を停止します
IBM j9	バランスのとれた	モノリシック、ストップ・ザ・ワールド、コピー	ほとんどの場合、デフラグ中に人気に基づく地域の「圧縮」と同時に、世界を停止させます
IBM j9	最適化	モノリシック、ストップ・ザ・ワールド、コピー	パラレルマーク/スイープ、デフラグメンテーションにより世界が停止します
アズール	C4（継続的並行圧縮コレクター）	最適化と同時	最適化と同時

いくつかの詳細について説明します。



Oracle HotSpot ParallelGC



デフォルトでHotSpotのGC。 若い世代には「モノリシック」世界停止アルゴリズム（Copying Collector）、古い世代には「モノリシック」世界停止アルゴリズム（Mark / Sweep / Compact）を使用します。



Oracle HotSpot CMS



GCは、デフラグを行わずに、マーキングとクリーニングを同時に行うことで、古い世代で作業するときに発生する一時停止を可能な限り排除しようとしています。 ただし、OG関連のメモリ領域が大きく断片化されるとすぐに、stop-the-worldによるデフラグが呼び出されます。



CMSガベージコレクションサイクルはいくつかのステージで構成され、主なステージは次のとおりです。



・初期マーク：CMSは、非常に短い世界停止で始まります。この間、ガベージコレクターは、アプリケーションによって作成されたオブジェクトへのいわゆるルートリンクを見つけます。



・同時マーク：この段階で、CMSはルートオブジェクトから到達可能なすべてのオブジェクト、つまり、ガベージコレクターによって削除されるべきではないすべての「リビング」オブジェクトをマークします。 この段階は、アプリケーションと同時に実行されます。



・再マーキング（注釈）：同時マーキングフェーズの間、アプリケーションフローは引き続き動作し、その時点で新しいオブジェクトを作成し、リンクを変更できるため、この段階の終わりまでに、すべての生きているオブジェクトがマーキングされる保証はありません。 この問題を解決するために、CMSはアプリケーションをもう一度一時停止してマーキングを完了し、前のステップでユーザースレッドによって変更されたすべてのオブジェクトをチェックします。 再マーキングにはかなりの時間がかかるため、マルチプロセッサマシンでは、この段階は複数の並列スレッドによって実行されます。



・同時スイープ：再マーキングフェーズの完了後、アプリケーション内のすべての生きているオブジェクトがマークされ、同時クリーニングフェーズ中に、CMSは見つかったすべてのガベージ（すべてのマークされていないオブジェクト）を削除します。 この手順では、アプリケーションを一時停止する必要はありません。



したがって、CMSは、OldGenをクリーニングするすべての作業をいくつかの部分に分割し、その一部をアプリケーションと同時に実行できるため、長時間の世界停止が回避されます。 同時に、アルゴリズムの特性により、CMSによって実行される作業の合計量は、シーケンシャルガベージコレクターと比較して大きくなります（たとえば、再マーキングの必要性のため）。その結果、CMSを使用すると、アプリケーションの全体的なパフォーマンスがわずかに低下する場合があります。



IBM J9 optthruputは、ほぼ同じことを行います。



Oracle HotSpot G1GC（ガベージファースト）



世代別のガベージコレクターですが、動作原理は異なります。 すべてのヒープは、固定サイズの領域に分割されます。 領域のセットは動的に生成され、エデン、サバイバースペース、または古い世代（OG）になります。 オブジェクトが1つの領域に収まらない場合、隣接する一連の領域に格納され、「巨大」と呼ばれます。 一部の地域は他の地域よりも人気があると想定されています。 メモリクリーニング手順を実行すると、次のことが発生します。



1）GCが行われる地域が選択されます-若い世代全体と、生き物がない古い世代の人気のない地域



2）新しいオブジェクトと変更されたリンクをキャッチするための再マーキング、ストップザワールドは短期間設定されます。



3）「To」とマークされた領域へのコピー。これにより、部分的な「圧縮」があります。



また、記憶セット-領域からオブジェクトへのリンクの場所に関する情報があります。これにより、メモリのさまざまな部分でいくつかの独立した領域を使用し、いわゆる放棄することができます。 無料リスト。 このGCは、以前のものよりも大きなヒープで機能し、原則として、10〜15 GBのサイズのヒープに対して許容可能なパフォーマンスを提供できます。 それにもかかわらず、膨大な数のバグと、G1が人気のある地域の強力な断片化により世界を止めざるを得ないという事実と同様に、その魅力は増しません。 このGCのもう1つの欠点は、他のGCと比較して最大スループットが低下することです。



IBM J9 Balancedは同じことを行います。



アズールc4



このガベージコレクターは、その説明で次のことを宣言しているため、最大の関心を引き起こします。



「 Azul JVMを搭載した、独自のC4アルゴリズム（Continuously Concurrent Compacting Collector）を使用した完全にバックグラウンドの同時ガベージコレクター。 C4は、若い世代と古い世代の両方の世代を同時に最適化します。 他のアルゴリズムとは異なり、「ほとんどの場合同時」ではありませんが、実際には常にアプリケーションスレッドで同時に動作します。 stop-the-worldが呼び出されることはありません。 C4はLoaded Value Barrier（LVB）を使用して各リンクをチェックし、変更された各リンクは「自己修復」メソッドを使用してキャッチされます。 C4は、すべてのリンクが単一のGCパスでラベル付けされるようにします。 また、オブジェクトの移動が保証され、オブジェクトへのリンクがアプリケーションと同時に変更されます。その操作を妨げることなく、「世界を停止」することもありません 」



また、この製品の説明には、GCの現在の実装と比較した以下のグラフがあります。



スループット：





応答時間別：



スループットに一定のパリティがあり、ほとんどの場合、並列GCの方が優れていることがわかります。応答時間とヒープサイズを示すグラフでは、すべてのケースでAzul C4が確実に先行していることがわかります。 ただし、これらのグラフを単に見るだけで、「従来の」GCと比較してこのような大きな違いがどこから生じるのかを理解できる詳細を掘り下げて考えないのは間違っているでしょうか。 これを行うには、Azul C4が動作するアルゴリズムを解析する必要があります。



上記で、「世界停止」ポーズの発生につながる2つの主な理由について述べました。 これは、古い世代のメモリ領域の断片化と、 生きているオブジェクトのマーキングです 。 メモリを最適化しないと、遅かれ早かれ「メモリ不足」が発生します。アプリケーションと同時にメモリを最適化すると、誤ったデータが取得されます。 マーキングの場合、「生きている」オブジェクトをメモリから削除する危険性があり、その結果、アクセスできないというメッセージが表示されます。



これらの問題を解決するために、Azul C4ガベージコレクターアルゴリズムは、いわゆる読み取りバリアのハードウェアベースのエミュレーションを使用します。 Azul C4では、LVB（Load Value Barrier）と呼ばれ、ガベージコレクターとアプリケーションが並行して動作することを保証するのに役立ちます。



また、Azul C4は2つの世代を使用します。最も若い世代と古い世代で、これらの世代が占有するメモリはアプリケーションと同時に最適化されます。 下の図は、ゴミをきれいにするための主な手順を示しています。 それらの3つ-Mark、Relocate、Remapがあります。 リマップとマークは同時に実行できることに注意してください。 各段階で何が起こりますか？





マーク



この段階で、ルートオブジェクトから到達可能なすべてのオブジェクトがメモリ内でマークされます。 そのようなオブジェクトは「生きている」とマークされ、他のすべてのオブジェクトは「死んでいる」ことを意味し、クリーニングできます。 アプリケーションと同時に実行され、「世界を止める」一時停止を引き起こしません。 一般に、CMSの「同時マーク」ステージに似ていますが、いくつかの重要な違いがあります。 まず、ラベル付けに加えて、Azul C4はメモリの各ページの「ライブ」オブジェクトの数もカウントします。 この情報はさらに、メモリ内で転送およびデフラグするページを選択するために使用されます。 次に、Azul C4アルゴリズムは、64ビットリンクでアーキテクチャ的に予約されたNMTビットを使用して、ライブオブジェクトのすべてのリンクを追跡します。 このビット、NMT（Not Marked Through）は、GCが「パス」した場合、または「マークなし」としてリンクを「マーク済み」としてマークすることを目的としています。 したがって、Azul C4は、到達可能なすべてのオブジェクトを「ライブ」としてマークし、また、「通過」したすべてのリンクを「マークスルー」としてマークします。 Markステージが開始されるとすぐに、NMTビットが「not mark through」に設定されたリンクを「追跡」しようとするアプリケーションスレッドは、LVBの「読み取りバリア」によってインターセプトされます。 このバリアのハードウェアエミュレーションはNMTビットの機能を認識しており、アプリケーションスレッドが「not mark through」とマークされたリンクにアクセスしないようにします。 アプリケーションスレッドのいずれかがこれを行おうとすると、プロセッサはGCへの割り込み（トラップ）を引き起こします。 割り込みは、それを引き起こした状況を次のように処理します：リンクをGCリストに入れ、NMTビットを「マークスルー」位置に入れ、有効性リンクがロードされたオブジェクトのNMTビットをチェックします（「マークスルー」状態でなければなりません）。 割り込みが処理されると、アプリケーションスレッドが再開します。 このメカニズムを使用すると、すべての「生きている」オブジェクトを1回のパスでマークできます。再ラベル付け（CMSのように）や「世界の停止」を引き起こすことはありません。 また、この中断自体の処理中に中断の原因を除去すると、「セルフメディケーション」の効果があります。 同じ理由が再び中断を引き起こすことを許可していないため、ラベリングに関する最終的かつ予測可能な作業範囲が保証されます。



一般に、割り込みメカニズムにより、1回のパスで「ライブ」オブジェクトのマーキングが可能になり、同時に「世界の停止」ポーズが発生しません。



再配置



この時点で、GCはデッドオブジェクトが占有していたメモリを解放します。 同時に、彼は「生きている」オブジェクトを別のメモリ領域に転送し、それによって最適化と圧縮を行います。 効率を高めるため、Azul C4は「デッド」オブジェクトの数が比較的多いページを最初にクリアするために、最後の段階（マーク）でカウントされたオブジェクトの数を使用します。 これらのページには「生きている」オブジェクトがほとんどないので、それらの転送には短い時間がかかり、同時に最初の段階でより多くのメモリを解放して、アプリケーションで使用できるようにします。 「デッド」オブジェクトによって占有されているメモリが完全にクリアされると、ステージは終了します。 同時に、「生きている」オブジェクトは、非常に断片化されたページからのみ転送されます。



ステージの開始時に、メモリの特定のページへのアクセスを制限するためにメモリ保護メカニズムを使用して、ガベージコレクタは「ライブ」オブジェクトのメモリの他のページへの転送を開始します。 開始アドレスと新しいアドレスに関する情報は、「From」スペースとは別に取り出される「Forwarding Pointers」を持つ特別な配列に保存されます。 すべての「生きている」オブジェクトが転送されるとすぐに、アプリケーションスレッドが物理メモリを使用できるようになります。 LVBは、「ライブ」オブジェクトの転送またはこのオブジェクトのアドレスの再定義のプロセスが行われるメモリページへのスレッドへのアクセス試行を決定するために使用されます。 ストリームコールをインターセプトし、リンクの値をTranslation Look-aside Buffer（TLS）内のリンクと比較します。 値が現在進行中のリンクと一致する場合、割り込みが呼び出されます。 この割り込みは、次のアクションを実行します。ForwardingPointers配列の情報を使用して、オブジェクトが既に移動されているかどうかが判断されます。 オブジェクトが既に新しいメモリページに移動されている場合、オブジェクトへの新しいリンクがストリームに返され、ロードされたオブジェクトへのリンクのアドレスが再定義され、将来新しいリンクが使用されるようになります。 オブジェクトがまだ移動されていない場合、割り込みは、ガベージコレクタがこのオブジェクトのあるメモリページを処理するのを待たずに、このオブジェクトを移動します。 その後、フローが再開します。 前の段階と同じ「自己治療」の効果を使用すると、決定論的な時間枠で運動の段階を完了することができます。 また、メモリ内のオブジェクトを移動するステップを続行するよりも、今すぐマーキングステップを実行する方が効率的であるとガベージコレクタが決定した場合、移動ステージを強制的に完了することができます。



この段階を考えるとき、アルゴリズムと割り込みメカニズムのこの動作により、スレッドはガベージコレクターがアドレスの移動と書き換えの処理を完了するまで待機せず、ガベージコレクターがフローと実際に同時に動作し、「停止- the-world「一時停止。



リマップ



この段階では、移動されたすべてのオブジェクト参照のアドレス書き換えが完了し、移動されたオブジェクトのヒープ内の古い場所への参照がないことが保証されます。 これらのリンクは、再定義段階の最初に存在する場合があります。これは、ヒープに、移動後にスレッドがアクセスしなかったオブジェクトへのリンクが含まれている可能性があるためです。 アドレス書き換えフェーズが完了すると、メモリ保護メカニズムが無効になり、Forwarding Pointers配列は不要になります。 アドレスの書き換えは次のように実行されます。heap-e内のすべての「ライブ」オブジェクトがスキャンされ、それらが新しいメモリページに移動されたオブジェクトを指す場合、リンクが再定義されます。 この段階はマーキング段階と一致し、同時に実行されます。 マーキングプロセスは、生きているオブジェクトを検出してマークし、NMTビットを「マークスルー」として設定します。 同時に、アドレス再割り当てプロセスは、移動されたオブジェクトへのリンクを見つけ、新しいアドレスに従ってそれらを再定義します。 マーキングおよびアドレス書き換えプロセスのプロセス全体を通して、「読み取りバリア」メカニズムは、転送されたオブジェクトにアクセスするアプリケーションスレッドを「キャッチ」し続け、新しいロケーションアドレスをストリームに返す割り込みを引き起こします。



したがって、Azul C4は、「世界停止」の一時停止を引き起こすことなく、アドレスの書き換えだけでなく、同時マーキングを実行できます。



Azul C4アルゴリズムの理論的な説明を要約すると、アプリケーションがガベージコレクターと同時に動作することを本当に可能にしていると言えます。 LVBメカニズムは、JVMの全体的なスループットをわずかに低下させますが、「世界停止」の休止を完全に排除して、応答時間を最小限に安定させます。 インターネット上でサービスを提供することを専門とする企業や、応答時間がビジネスにとって重要なアプリケーションにとって、Azul C4は最も魅力的なJVMのように見えます。



これにもかかわらず、理論は実践によって確認されなければなりません。 人生では、Azul JVMはハードウェアとしても仮想マシンとしても提供されます。 Azul Vega 3ハードウェアプラットフォームは、金融会社ですでに確立されています。 仮想Azul JVMの実装は、一部はx86ハードウェアに展開できるという事実、一部はJavaベースのアプリケーションに向けられたタスクがより深刻になっているという事実により、世界で人気を博しています。 ところで、Azul C4はAzul JVMの唯一の利点ではありません。Azulを競合他社と区別するいくつかの違いがあります。 これらの利点の詳細な説明には、この記事に必要なだけのスペースが必要です。したがって、Azul JVM全般を検討できる別の記事に残しておくことをお勧めします。 名前による場合-これはDirectPathVMTM、オプティミスティックスレッドの同時実行、アプリケーション実行の監視とプロファイリングです。



Azul SystemsのWebサイトでは、Azul-aの利点が応用されている人生の事例を多数見ることができます。



Azul JVMを使用している企業



個人的な練習から、大企業の取引会社であるAzul JVMの実装例を紹介できます。





JVM構成：

ネイティブ構成	アズール構成
-Xms2g -Xmx2g -XX：+ UseConcMarkSweepGC -XX：+ UseParNewGC -XX：TargetSurvivorRatio = 80 -XX：CMSInitiatingOccupancyFraction = 85 -XX：SurvivorRatio = 8 -XX：MaxNewSize = 320m -XX：NewSize = 320m -XX：MaxTenuringThreshold = 10	-Xms3g –Xmx3g

上記のすべてをまとめると、Azul C4で実装されたコンセプトは実際に実際に機能し、最大1テラバイトのサイズのヒープを持つことができ、ヒープサイズの設定とGCの調整に伴う頭痛を解消できます。安定した最小限のアプリケーション応答時間を実現します。



Azul C4 Algorithmデータシート