2 チューニングにおけるトレードオフの概要

この章では、Oracle JRockit JVMのチューニングにより、ガベージ・コレクションによる休止時間の短縮、アプリケーションのスループットの向上、メモリーの占有領域の縮小という各要件の間で妥協点を図る方法について説明します。

この章の内容は以下のとおりです。

• 2.1項「休止時間とスループット」

• 2.2項「パフォーマンスとメモリーの占有領域」

2.1 休止時間とスループット

JRockit JVMでは、ガベージ・コレクションの休止時間を短くするか、アプリケーション・スループットを最大化するか、どちらかを選ぶことができます。この項では、このトレードオフが存在する理由を説明します。

2.1.1 コンカレントとStop-the-World

ガベージ・コレクションの休止時間とアプリケーションのスループットの間のトレードオフは、ガベージ・コレクションの休止時間を短くするモーストリ・コンカレント・ガベージ・コレクション方式の影響も受けています。ガベージ・コレクションの期間中Javaスレッドを停止するガベージ・コレクション・アルゴリズムがどれほど効率的であっても、ガベージ・コレクション期間に部分的にでもJavaスレッドを引き続き実行できるガベージ・コレクション・アルゴリズムの方が、個々のガベージ・コレクションの休止時間が短くなります。コンカレント・アルゴリズムにはさらに作業が必要です。これは、新しいオブジェクトが作成され、オブジェクト間の参照がガベージ・コレクション中に変更されるためです。これらの変更はすべて追跡する必要があるため、オーバーヘッドが発生します。また、ガベージ・コレクタがすべての変更を処理する必要があるため、さらに追加の作業が発生します。結果的に、Javaスレッドの休止中のガベージ・コレクタの作業量が多いほど、全体的に必要な処理量は少なくてすみます。

2.1.2 圧縮による休止時間とスループット

ライブ・オブジェクトのブロック間で、割り当てられたオブジェクトには小さすぎるメモリーのチャンクが解放されると、マーク・アンド・スイープ・ガベージ・コレクション・モデルによってヒープの断片化が発生する場合があります。ヒープを圧縮すると、この断片化は減少します。断片化が発生すると、オブジェクトの割当てが難しくなり、ガベージ・コレクションの頻度が増すため、全体のスループットに負の影響があります。JRockit JVMは、ガベージ・コレクションごとにヒープの部分圧縮を行います。この圧縮は、Javaスレッドの休止中に行われます。オブジェクトの移動には時間がかかるため、移動するオブジェクトが多いほど、圧縮にかかる時間が長くなります。圧縮の量を減らすと圧縮による休止時間も短くなりますが、断片化が進行するため、全体のスループットは低下します。

2.2 パフォーマンスとメモリーの占有領域

メモリー・リソースが少ないマシン上で実行するアプリケーションでは、メモリーの占有領域が小さいことが求められます。メモリーの占有領域を小さくし、アプリケーション全体のスループットを高くして、ガベージ・コレクションの休止時間を短くする、という要件をすべて満たすことはできません。この項では、このトレードオフの理由を説明します。

2.2.1 ヒープ・サイズとスループット

ヒープが大きいと、ガベージ・コレクションの頻度と断片化が減少するため、アプリケーションのスループットが向上します。ただし、ヒープが大きいと、Javaプロセスのメモリーの占有領域も大きくなります。

2.2.2 ブックキーピングと休止時間

休止時間を短くすることを優先して最適化されたガベージ・コレクション・モードを使用する場合、Oracle JRockit JVMは、より高度なブックキーピングを使用してヒープ内の変更、圧縮されたオブジェクトへの参照などを追跡します。これらはすべて、メモリーの占有領域を増やします。ブックキーピングのメモリーの使用状況をチューニングする場合は、別のガベージ・コレクション・モードまたは方式を選択します。