|
|
Oracle JRockit JVM をチューニングすると分かりますが、ガベージ コレクションによる休止時間は短く、アプリケーションのスループットは高く、メモリの占有領域は少なくてすむ、といった要件をすべて満たすようにチューニングすることはできません。この節では、これらのトレードオフと、その背後にある理由について説明します。以下の事柄を説明します。
JRockit JVM では、ガベージ コレクションの休止時間を短くするか、アプリケーション スループットを最大化するか、どちらかを選ぶことができます。直観的には、ガベージ コレクションの休止時間が短いと、アプリケーションのスループットも最大化するように思えるので、一方を選択しなければならない理由を疑問に思うかもしれません。この節では、このトレードオフの背後にある理由を説明します。
ガベージ コレクションの休止時間とアプリケーションのスループットの間のトレードオフは、ガベージ コレクションの休止時間を短くするモーストリ コンカレント ガベージ コレクション方式の影響も受けています。ガベージ コレクションの期間中すべての Java スレッドを停止するガベージ コレクション アルゴリズムがどれほど効率的であっても、ガベージ コレクション期間に部分的にでも Java スレッドが続行できるガベージ コレクション アルゴリズムの方が、結果的には個々のガベージ コレクションの休止時間が短くなります。コンカレント アルゴリズムには、新しいオブジェクトが作成されると、ガベージ コレクション中にオブジェクト間の参照が変更されるため、ブックキーピングやその他の作業がさらに必要です。これらの変更はすべて追跡する必要があり、これだけで多少のオーバーヘッドが発生します。また、どこかの時点でガベージ コレクタがすべての変更を処理する必要があるため、さらに追加の作業が発生します。つまり、Java スレッドの休止中のガベージ コレクタの作業量が多いほど、全体の作業量は少なくてすみます。
生存しているオブジェクトのブロック間でメモリの小さなチャンクが解放されるときに、マーク アンド スイープ ガベージ コレクション モデルによって、ヒープの断片化が発生する場合があります。ヒープを圧縮すると、この断片化が減少します。断片化が発生すると、オブジェクトの割り当てが難しくなり、ガベージ コレクションの頻度が増すため、全体のスループットにマイナスの影響があります。JRockit JVM JRockit は、ガベージ コレクションごとにヒープの部分圧縮を行います。この圧縮は、Java スレッドの休止中に行われます。オブジェクトの移動には時間がかかるため、移動するオブジェクトが多いほど、圧縮にかかる時間が長くなります。トレードオフはシンプルです。圧縮の量を減らすと圧縮による休止時間も短くなりますが、断片化が進行するため、全体のスループットは低下します。
メモリ リソースが少ないマシン上で実行するアプリケーションでは、メモリの占有領域が小さいことが求められます。しかし、メモリの占有領域を小さくし、アプリケーション全体のスループットを高くして、ガベージ コレクションの休止時間を短くする、という要件をすべて満たすことはできません。この節では、このトレードオフの理由を説明します。
ヒープが大きいと、ガベージ コレクションの頻度が下がり、断片化によるマイナスの影響も軽減されるため、結果的にアプリケーションのスループットが向上します。一方、ヒープが大きいと、Java プロセスのメモリの占有領域も大きくなります。
休止時間を短くすることを優先して最適化されたガベージ コレクション モードを使用する場合、Oracle JRockit JVM は、より高度なブックキーピングを使用してヒープ内の変更 (圧縮されたオブジェクトへの参照など) をトラックします。これは、メモリの占有領域を増大させます。別のガベージ コレクション モードまたは方式を選択する以外、ブックキーピングのメモリの使用状況をチューニングすることはできません。
|