2 エルゴノミクス

ガベージ・コレクタ、ヒープおよびランタイム・コンパイラのデフォルト選択

server-classマシンと呼ばれるクラスのマシンは、次を搭載したマシンとして定義されています。

• 2個以上の物理プロセッサ

• 2GB以上の物理メモリー

server-classマシンでは、次がデフォルトで選択されています。

• スループット・ガベージ・コレクタ

• 初期ヒープ・サイズ: 物理メモリーの1/64 (最大1GB)

• 最大ヒープ・サイズ: 物理メモリーの1/4 (最大1GB)

• サーバー・ランタイム・コンパイラ

64ビット・システムの初期ヒープ・サイズと最大ヒープ・サイズについては、「パラレル・コレクタ」の「デフォルト・ヒープ・サイズ」を参照してください。

server-classマシンの定義は、Windowsオペレーティング・システムのバージョンが動作している32ビット・プラットフォームを除くすべてのプラットフォームに適用されます。 表2-1「デフォルト・ランタイム・コンパイラ」に、各種プラットフォーム別のランタイム・コンパイラの選択を示します。

^脚注1クライアントは、クライアント・ランタイム・コンパイラが使用されることを意味します。 サーバーは、サーバー・ランタイム・コンパイラが使用されることを意味します。

^脚注2server-classマシンであってもクライアント・ランタイム・コンパイラを使用するポリシーが選択されています。 これを選択した理由は、従来、このプラットフォームとオペレーティング・システムの組合せではクライアント・アプリケーション(対話型アプリケーションなど)の方がより頻繁に実行されていたためです。

^脚注3サーバー・ランタイム・コンパイラのみがサポートされています。

動作ベースのチューニング

Java SEには、パラレル・コレクタ用に、アプリケーションの特定動作の実現をベースとする2つのガベージ・コレクション・チューニング・パラメータ(最大一時停止時間目標とアプリケーション・スループット目標)が用意されています。「パラレル・コレクタ」を参照してください。 (この2つのオプションは他のコレクタでは使用できません。) これらの動作は必ずしも満たされるわけではありません。 アプリケーションには、少なくともすべてのライブ・データを収容できる大きさのヒープが必要です。 また、最小ヒープ・サイズではこれらの望ましい目標を達成できない場合があります。

チューニング方法

デフォルト最大ヒープ・サイズよりも大きいヒープが必要なことがわかっている場合を除いて、ヒープの最大値を選択しないでください。 アプリケーションにとって十分なスループット目標を選択してください。

ヒープは選択されたスループット目標に対応するサイズに拡大/縮小されます。 アプリケーションの動作に変更があると、ヒープが拡大/縮小される場合があります。 たとえば、アプリケーションが高速な割当てを開始すると、ヒープは同じスループットを維持するために拡大します。

ヒープが最大サイズまで大きくなり、スループット目標が満たされていない場合は、最大ヒープ・サイズがスループット目標に対して小さすぎます。 最大ヒープ・サイズをプラットフォームの総物理メモリーに近い値、ただしアプリケーションのスワッピングを引き起こさない程度に設定してください。 アプリケーションを再実行します。 それでもスループット目標が満たせない場合は、アプリケーション時間の目標がプラットフォームで使用可能なメモリーに対して高すぎます。

スループット目標は満たせるけれども、一時停止が長すぎる場合は、最大一時停止時間目標を選択します。 最大一時停止時間目標を選択すると、スループット目標が満たされなくなる可能性があるので、アプリケーションにとって受け入れ可能な妥協値を選択してください。

ガベージ・コレクタでは相反する目的を満たそうとするので、ヒープ・サイズの変動はよくあることです。 これは、アプリケーションが定常状態になった場合にも当てはまります。 スループット目標(大きなヒープが必要)を達成しようとする圧力は、最大一時停止時間と最小フットプリントの目標(いずれも小さなヒープが必要)と相反します。