初期ヒープ・サイズおよび最大ヒープ・サイズ

ガーベッジ・コレクター (GC) の操作を理解することは、ヒープを効率的に管理するための初期ヒープ・サイズと最大ヒープ・サイズの設定に役立ちます。

70 + (70 * 43/100)

通常、最小ヒープ・サイズと最大ヒープ・サイズを同じ値に設定することはお勧めしません。 ヒープがフルになるまでガーベッジ・コレクションが先延ばしされるためです。 そのため GC の初回実行時に、プロセスの所要時間が長くなります。 また、ヒープが断片化され、ヒープの圧縮が必要となる確率が高まります。 アプリケーションで必要とされる最小ヒープ・サイズでアプリケーションを開始してください。 これにより、GC が開始された場合に、ヒープが小さいために、頻繁に効率よく実行されるようになります。

GC により十分な量のガーベッジを検出できない場合、圧縮が実行されます。 GC によって十分なガーベッジが検出された場合、またはヒープ拡張の他の条件のいずれかが満たされた場合 ( OpenJ9 ユーザー資料の「 ヒープ割り振り 」を参照)、GC によってヒープが拡張されます。

そのため、アプリケーションは通常、ヒープがいっぱいになるまで実行されます。 続けて、連続するガーベッジ・コレクション・サイクルにより、ガーベッジが復旧されます。 ヒープがライブ・オブジェクトでいっぱいになると、GC によりヒープの圧縮が行われます。 必要な量のガーベッジが復旧されていない場合は、GC によりヒープの拡張が行われます。

前述のとおり、アプリケーションの要求が高まると、GC によりヒープの圧縮が行われるため、ヒープは、元のヒープの下部にオブジェクトのセットが圧縮された状態で拡張されます。 圧縮は、圧縮が必要であることが分かった時点で最小のヒープ・サイズに対して実行されるため、このプロセスはヒープの効率的な管理方法です。 ヒープが増大すると、最小ヒープ・サイズにより圧縮が実行されます。 アプリケーションに最初に含まれるオブジェクトが、キー・セットまたはルート・セットとなることが多いため、そのようなオブジェクトを早期に圧縮すると、より寿命の短いオブジェクトに残りのヒープが解放される、という事例もあります。

最終的に JVM には、ヒープの下部に寿命の長いオブジェクトすべてが圧縮された、最大サイズのヒープが含まれます。 圧縮は、圧縮を行うことによる負荷が最も低いフェーズで行われました。 ヒープの拡張に必要な処理量およびメモリー使用量は、非常に大きな断片化されたヒープを収集して圧縮する場合のコストに比べ、ごくわずかです。