|
|
メモリ管理とは、結局のところ、オブジェクトをどのように割り当てるかということです。メモリ管理システムは、新しいオブジェクトのための空き領域を探す役割と、古いオブジェクトにガベージ コレクションを行って新しいオブジェクトのための空き領域を作成する役割を果たします。Java アプリケーションが割り当てるオブジェクトの数が多いほど、メモリ管理に多くのリソースが使用されます。メモリ管理システムが適切にチューニングされていれば、ガベージ コレクションによるオーバーヘッドは最小限に抑えられ、オブジェクトの割り当てが高速化します。Oracle JRockit JVM におけるメモリ管理の機能の詳細については、「メモリ管理の概要」を参照してください。この節では、JVM のメモリ管理システムのチューニングに使用できる重要なオプションについて説明します。以下の事柄を説明します。
ヒープは、Java オブジェクトが格納されている領域です。ヒープ サイズは、JVM のパフォーマンスに影響し、結果として Java アプリケーションのパフォーマンスにも影響します。
JVM が世代別のガベージ コレクション方式を使用する場合、ヒープの一部がナーサリとして確保されます。小規模なオブジェクトはナーサリ (「若い領域」とも呼ばれる) に割り当てられます。ナーサリが一杯になると、若いコレクションが行われ、ナーサリに存在する古くなったオブジェクトが古い領域 (ヒープの残りの領域) に移動します。
最近割り当てられたオブジェクトと、ナーサリ内に一定の期間存在していたオブジェクトを見分けるために、JVM は保持領域を使用します。保持領域には、ナーサリ内に最近割り当てられたオブジェクトが保管されます。またこの領域は、次の若いコレクションまではガベージ コレクションは行われません。
コマンド ライン オプション : -Xms:<min size> -Xmx:<min size>
ヒープ サイズは、割り当ての速度、ガベージ コレクションの頻度、ガベージ コレクションの実行時間に影響します。ヒープが小さいとすぐに一杯になるため、頻繁にガベージ コレクションを行う必要があります。また、ヒープが小さいと断片化しやすいため、オブジェクトの割り当てが遅くなります。ヒープが大きいと、ガベージ コレクションの実行時間のオーバーヘッドが少なくてすみます。システム内の利用可能な物理メモリよりもヒープが大きいと、ディスクにページアウトしなければならないため、アクセス時間が長くなり、特にガベージ コレクション中にアプリケーションのフリーズを招くおそれがあります。
通常は、ヒープのページアウトが発生しない限り、大きなヒープによるオーバーヘッドは、ガベージ コレクション頻度の増加や割り当て速度によって発生するオーバーヘッドよりも小さくてすみます。このように、ヒープ サイズは、利用可能な物理メモリを超えない範囲でできるだけ大きく設定するのがよいでしょう。
java -Xms:1g -Xmx:1g MyApplication
これにより、ヒープ サイズが 1 GB に固定された JVM が起動します。
デフォルト値と制限については、「-Xms」および「-Xmx」の各ドキュメントを参照してください。
アプリケーションで決められた最適なヒープ サイズが分かっている場合は、-Xms および -Xmx をその最適値に設定することをお勧めします。このように設定すると、起動時から、最適なヒープ サイズに調整された環境でアプリケーションを実行できます。
64 ビット システムでは、メモリ アドレスが 64 ビット長であるため、32 ビット アドレスのシステムよりも多くのメモリに対応できます。一方、参照ごとに 2 倍のメモリが必要になります。 64 ビット システムにおけるメモリの使用状況を緩和するために、JRockit JVM は圧縮参照を使用します。圧縮参照は参照を 32 ビットに削減します。これは、ヒープ全体を 32 ビットで対応できれば、使用することが可能です。使用可能な場合、圧縮参照は常にデフォルトで有効になっています。このように、64 ビット システムでは、ライブ データが 3 ～ 4 GB を超えない限り、4 GB 未満の範囲で最大ヒープ サイズを設定したほうが効果的です。
コマンド ライン オプション : -Xns:<nursery size>
ナーサリのサイズは、割り当ての速度、ガベージ コレクションの頻度、ガベージ コレクションの実行時間に影響します。ナーサリが小さいとすぐに一杯になるため、頻繁にガベージ コレクションを行わなければなりませんが、ナーサリを大きくしてもガベージ コレクションにかかる時間はわずかに長くなるだけです。ごく小さいナーサリには、若いコレクションが開始する前に生存期間の過ぎたオブジェクト数が少ないか、または一切ないため、ほとんど役に立ちません。あまりにも大きいナーサリも役に立ちません。このようなナーサリでは、古い領域に大規模オブジェクトを割り当てるために発生するヒープ全体のガベージ コレクション間に若いコレクションが行われないためです。
アプリケーション スループットの最大化を実現する最適なナーサリ サイズは、古いコレクションではなく、若いコレクションによって、できる限り多くのオブジェクトのガベージ コレクションが行われることです。この値は大体、空きヒープの半分のサイズです。JRockit JVM R27.3.0 以降のバージョンでは、スループットを優先して最適化する動的ガベージ コレクションのモードは -Xgcprio:throughput です。静的世代別パラレル ガベージ コレクタ -Xgc:genpar は、ほぼ最適値になるようにナーサリ サイズを動的に設定します。
スループットを実現する最適なナーサリ サイズは、通常はかなり大きいため、若いコレクション時間が長くなります。若いコレクションの実行中はすべての Java スレッドが休止するため、ナーサリ サイズを最適値より低く設定し、若いコレクションの休止時間を短かくしたほうがよい場合があります。
ナーサリ サイズを設定するには、コマンド ライン オプション -Xns:<size> を使用します。次に例を示します。
これにより、ナーサリ サイズが 100 GB に固定された JVM が起動します。
デフォルト値と制限については、「-Xns」のドキュメントを参照してください。
コマンド ライン オプション : -XXkeepAreaRatio:<percentage>
保持領域のサイズは、古いコレクションと若いコレクションの両方の頻度に影響します。保持領域が大きいと、若いコレクションが頻繁に行われますが、保持領域が小さすぎると、オブジェクトが早期に昇格するときに古いコレクションが頻繁に行われます。
最適な保持領域のサイズは、昇格率を低く維持できる範囲で、できるだけ小さい値です。昇格率は、JRA 記録 (詳細は「Oracle JRockit Mission Control ツールの使用」を参照)、-Xverbose:memory=debug を実行すると出力される冗長出力、および -XgcReport によって出力されるガベージ コレクション レポートで確認できます。デフォルトの保持領域はナーサリの 25% です。
ナーサリの割合として定義される保持領域のサイズは、コマンド ライン オプション -XXkeepAreaRatio:<percentage> を使用して変更できます。次に例を示します。
java -XXkeepAreaRatio:10 MyApplication
これにより、ナーサリ サイズの 10% の保持領域が設定された JVM が起動します。
オブジェクトのガベージ コレクションはいわゆる必要悪です。ガベージ コレクションを行わないと、自動メモリ管理システムは機能しません。アプリケーション開発者が何らかの手段でメモリを再利用しない限り、システム内のすべてのメモリはすぐに使い尽くされ、以降のメモリ割り当てが不可能になり、アプリケーションが実行できなくなります。
ガベージ コレクションの影響は、選択したガベージ コレクションの方法に応じて、様々な手法で分散させることができます。JRockit JVM には、ガベージ コレクション方式を 1 つまたは組み合わせて使用する、様々なガベージ コレクションのモードがあります。ガベージ コレクションのモードは、所定の目標を達成するのに最適なガベージ コレクション方式を選択する動的なモードと、ユーザ自身がガベージ コレクション方式を選択できる静的なモードのいずれかです。コマンド ライン オプション -XgcPrio:<mode> を使用して動的なガベージ コレクションのモードを選択するか、-Xgc:<strategy> で静的なガベージ コレクションを設定します。
動的なガベージ コレクションのモードは、使用するモードに応じて特定の目的を優先して最適化されるため、実行時にメモリ管理システムの調整を行います。動的なガベージ コレクションのモードには、以下の 3 つがあります。
動的なガベージ コレクションのモードは、高度なヒューリスティックを使用して、以下に示すパラメータを実行時に調整します。
これらのパラメータを手動で調整するには時間がかかるため、このプロセスを省略したい場合は、または使用しているアプリケーションが静的な環境に適さない場合は、動的なガベージ コレクションのモードを使用します。
コマンド ライン オプション : -XgcPrio:throughput
アプリケーションのスループットを優先して最適化された動的なガベージ コレクションのモードは、必要最小限の CPU リソースしか使用しないため、Java アプリケーションに割り当てられる CPU サイクルが最大になります。JRockit JVM は、ガベージ コレクションの全期間を通して Java アプリケーションを停止し、利用可能なすべての CPU を使用してガベージ コレクションを行うパラレル ガベージ コレクション方式を使用することによって、これを実現します。個々のガベージ コレクションの停止時間は長くなる可能性がありますが、全体としては、ガベージ コレクタが消費する CPU 時間を必要最小限に抑えられます。
スループット モードは、高いスループットを必要とする一方で、ガベージ コレクションによる休止時間がときどき長くなってもあまり影響を受けないアプリケーションに使用します。
スループット モードは、JVM が -server モード (デフォルト) で実行される場合のデフォルトです。または、コマンド ライン オプション -XgcPrio:throughput を指定して有効にすることもできます。次に例を示します。
java -XgcPrio:throughput MyApplication
これにより、スループットを優先して最適化されたガベージ コレクション モードで JVM が起動します。
詳細については、「-XgcPrio」のドキュメントを参照してください。
コマンド ライン オプション : -XgcPrio:pausetime
動的なガベージ コレクションのモードは、可能な限り高いスループットを実現する一方で、ガベージ コレクションの休止時間を所定の目標休止時間以内に抑えられるように、休止時間を優先して最適化します。JRockit JVM は、ガベージ コレクション期間中のほとんどの間 Java アプリケーションを実行し続けることが可能なモーストリ コンカレント ガベージ コレクション方式と、ガベージ コレクションの全期間を通して Java アプリケーションを停止するパラレル ガベージ コレクション方式のどちらかを選択することができます。モーストリ コンカレント ガベージ コレクタでは、コンカレント フェーズにおいて変更の追跡が行われるため、追加のオーバーヘッドが発生し、ガベージ コレクションがより頻繁に発生します。これにより、全体のスループットは若干低下しますが、個々のガベージ コレクションによる休止時間を低く抑えることができます。
休止時間モードは、長いレイテンシの影響を受けやすいアプリケーション、たとえば、トランザクション時間を一定にする必要のあるトランザクション ベースのシステムなどで使用します。
休止時間モードは、コマンド ライン オプション -XgcPrio:pausetime を指定して有効にします。次に例を示します。
java -XgcPrio:pausetime MyApplication
これにより、休止時間の短縮を優先した最適化されたガベージ コレクション モードで JVM が起動します。
詳細については、「-XgcPrio」のドキュメントを参照してください。
コマンド ライン オプション : -XpauseTarget:<time in ms>
休止時間モードでは、目標休止時間を使用して休止時間を最適化します。目標休止時間を短く設定するとメモリ管理システムに課されるオーバーヘッドが増すために、目標休止時間は、アプリケーションのスループットに影響します。目標休止時間には、アプリケーションで許容される最長の値を設定してください。
休止時間モードの目標休止時間はデフォルトで 500 ミリ秒に設定されていますが、コマンド ライン オプション -XpauseTarget:<time in ms> を使用して変更することもできます。次に例を示します。
java -XgcPrio:pausetime -XpauseTarget:300ms MyApplication
これにより、短い休止時間と、目標休止時間の 300 ミリ秒を優先して最適化されたガベージ コレクション モードで JVM が起動します。
詳細については、「-XpauseTarget」のドキュメントを参照してください。
コマンド ライン オプション : -XgcPrio:deterministic
確定的な休止時間を優先して最適化された動的なガベージ コレクションのモードは、ガベージ コレクションの休止時間を非常に短く抑え、さらに合計の休止時間が所定の枠内に収まるようにします。JRockit JVM は、ガベージ コレクション期間中もできる限り Java アプリケーションを実行し続けるモーストリ コンカレント ガベージ コレクタを使用して、これを実現します。
確定的モードは、レイテンシを短く確定的にする必要がある、トランザクション ベースのアプリケーションなどに使用します。
確定的モードは、コマンド ライン オプション -XgcPrio:deterministic を指定して有効にします。次に例を示します。
java -XgcPrio:deterministic MyApplication
これにより、短く確定的な休止時間を優先して最適化されたガベージ コレクション モードで JVM が起動します。
詳細については、「-XgcPrio」のドキュメントを参照してください。
確定的なガベージ コレクションの実行時間は、JRockit Mission Control Client の影響を受けることがあります。確定的なガベージ コレクタを使って WLRT を実行する場合、すべての JRockit Mission Control ツールが完全にサポートされますが、いくつかの点に注意する必要があります。
-Xmanagement-Xmanagement を使用しない場合に比べて、これが応答時間とパフォーマンスに影響を与える可能性があります。
JRockit Mission Control の詳細については、「Oracle JRockit Mission Control ツールの使用」を参照してください。
コマンド ライン オプション : -XpauseTarget:<time in ms>
確定的モードは、目標休止時間を使用して休止時間を最適化します。目標休止時間を短く設定するとメモリ管理システムに課されるオーバーヘッドが増すために、目標休止時間は、アプリケーションのスループットに影響します。目標休止時間には、アプリケーションで許容される最長の値を設定してください。
ガベージ コレクタは、ガベージ コレクションの休止時間を所定の目標休止時間以内に抑えることを目指します。これをどの程度まで達成できるかは、アプリケーションおよびハードウェアによって異なります。たとえば、ヒープが 1GB で、コレクション時のライブ データが平均で 30% 以下のアプリケーションを以下のハードウェアで実行する場合、目標休止時間は 30 ミリ秒で検証されます。
低速なハードウェアでアプリケーションを実行している、ヒープ サイズが異なる、ライブ データが多いなどの条件下では、確定的な動作が維持されなかったり、時間の経過に応じてパフォーマンスが低下するおそれがあります。高速なハードウェアを使用するか、ライブ データを少なくすると、目標休止時間を低く設定することができます。
確定的モードの目標休止時間はデフォルトで 30 ミリ秒に設定されていますが、コマンド ライン オプション -XpauseTarget:<time> を使用して変更することもできます。次に例を示します。
java -XgcPrio:deterministic -XpauseTarget:40ms MyApplication
これにより、確定的かつ短い休止時間と、目標休止時間の 40 ミリ秒を優先して最適化されたガベージ コレクション モードで JVM が起動します。
詳細については、「-XpauseTarget」のドキュメントを参照してください。
コマンド ライン オプション : -Xgc:<strategy>
静的なガベージ コレクション方式の主要なものは、以下の 4 つです。
静的なガベージ コレクション方式が選択されている場合、ガベージ コレクション方式が実行時に自動的に変更されることはありません。
明確かつ予測可能な動作を望んでいて、アプリケーションに最適なメモリ管理システムを JVM が検出するようにチューニングする場合は、静的なガベージ コレクション方式を使用してください。
アプリケーションに最適なガベージ コレクション方式を選択するには、次のワークフローに従います。
たとえば、Oracle WebLogic Sip Server は、各トランザクションに新しいオブジェクトを割り当てるトランザクション ベースのシステムであり、トランザクションのタイムアウトは短く設定されています。ガベージ コレクションによる休止時間が長いと、トランザクションがタイムアウトするため、モーストリ コンカレント ガベージ コレクションを使用する必要があります。つまり、gencon または singlecon のいずれかを使用します。トランザクションでは多数の一時的な (短い間しか生存しない) オブジェクトが生成されるため、二世代のガベージ コレクタ gencon を使用するとよいでしょう。
静的なガベージ コレクション方式は、コマンド ライン オプション -Xgc:<strategy> で設定します。たとえば、次のように指定します。
java -Xgc:gencon MyApplication
これにより、世代別コンカレント ガベージ コレクタが設定された JVM が起動します。
詳細については、「-Xgc」のドキュメントを参照してください。
(JRockit Mission Control 内の) JRockit Management Console の [メモリ] タブから、ガベージ コレクタ方式を実行時に変更することができます。ただし、次の条件に該当する場合を除きます。
詳細については、JRockit Management Console のオンライン ヘルプを参照してください。
コマンド ライン オプション: -XXgcTrigger:<percentage>
ガベージ コレクションで (マーク フェーズまたはスイープ フェーズで、あるいは両方のフェーズで) コンカレント方式を使用している場合、ガベージ コレクションのコンカレント フェーズでヒープの空き領域が不足するのを回避するために、JRockit JVM は古い世代のガベージ コレクションを開始するタイミングを自動的に調整します。このトリガは、前回のコレクション後にヒープ内で使用可能になった領域の大きさなどの要素に基づいて決定されます。JVM が使用可能な領域の最適化を動的に行おうとして、コンカレント ガベージ コレクション中に空きヒープがなくなる場合もあります。制限に達した場合、次のような冗長出力が、
[memdbg ] starting parallel sweeping phase
コマンド ラインの下に表示されます (-Xverbose:memdbg を設定した場合)。このメッセージは、コンカレント スイープを時間内に終了できなかったため、JVM が使用可能なすべてのリソースをスイープのために使用していることを表します。この場合は、パラレル スイープが行われます。JVM が正しく適合されず、この出力が繰り返し表示される場合は、パフォーマンスに悪影響が生じます。この事態を避けるには、-XXgcTrigger オプションを設定して、ヒープがまだ X % 残っている時点でガベージ コレクションがトリガされるようにします。次に例を示します。
java -XXgcTrigger=20 MyApplication
これで、空きヒープのサイズの 20% 未満が未使用のままになると、古い世代のガベージ コレクションがトリガされます。
(マーク フェーズとスイープ フェーズの両方で) パラレル ガベージ コレクション方式を使用している場合は、ヒープが完全に一杯になると古い世代のガベージ コレクションが実行されます。
圧縮は、割り当て済み領域のチャンクをヒープの下部に移動して、連続した空きメモリをヒープの上部に作成できるようにするプロセスです。JRockit JVM では、古いコレクションの実行時にヒープの部分的な圧縮を行います。使用されるガベージ コレクションのモードに応じて、圧縮領域のサイズと位置、および圧縮方式が、高度なヒューリスティックによって選択されます。
圧縮は、ガベージ コレクション中に行われますが、その間 Java スレッドはすべて休止します。多数のオブジェクトが割り当てられている大きな領域を圧縮すると、ガベージ コレクションの休止時間が長くなります。一方、圧縮が十分に行われない場合、ヒープが断片化し、パフォーマンスが低下します。断片化が長期にわたって進行すると、JRockit JVM は、ガベージ コレクションによる長い休止時間を伴うヒープの完全な圧縮を行うか、OutOfMemoryError を発生させなければならなくなります。
アプリケーションで長期的なパフォーマンスの低下が断続的に発生する場合、たとえば低下を続けていたパフォーマンスが突然良好な状態に戻り、その後再び低下し始める場合は、おそらく断片化の問題が発生しています。ヒープの断片化は古いコレクションが行われるたびに進行し、やがてオブジェクトの割り当てができなくなります。そうすると、JVM はヒープの完全な圧縮を行わざるを得なくなります。完全な圧縮を行うと断片化が解消しますが、次のガベージ コレクションを開始するとまた断片化が発生します。これは、JRockit Mission Control の Management Console を通じて JVM をモニタする
-Xverbose:memory 出力で確認するか、または JRA 記録を作成してガベージ コレクション データを検証することで確認できます。古いコレクション後に使用されるヒープの量が長期的に増加し続け、最大値に達した後、次の古いコレクション時に再び低下する場合は、断片化の問題が発生しています。
断片化の進行が遅く、一定している場合は、圧縮が適切にチューニングされています。
JRockit JVM の圧縮のヒューリスティックはガベージ コレクションの休止時間を短く均等に保つように設計されていますが、状況によっては、圧縮率を制限してガベージ コレクションの休止時間をさらに軽減したほうがよい場合もあります。ヒープの断片化を管理するために圧縮率を高くしたほうがよい場合もあります。圧縮を調整するには各種の方法があります。
コマンド ライン オプション : -XXcompactRatio:<percentage>
静的な圧縮率を設定すると、JVM で、古いコレクションのたびに指定の割合でヒープの圧縮が行われます。これにより、ヒープのレイアウトに基づいて動的に圧縮率を選択するヒューリスティックが無効になります。コマンド ライン オプション -XXcompactRatio:<percentage> を使用して、圧縮率にヒープの静的な割合を設定することができます。次に例を示します。
java -XXcompactRatio:1 MyApplication
この設定により、ヒープの 1% の静的圧縮率が設定された JVM が起動します。
詳細については、「-XXcompactRatio」のドキュメントを参照してください。
JVM で、デフォルトで選択される値よりも低い圧縮率または高い圧縮率を使用する場合は、このオプションを使用してください。圧縮率は、-Xverbose:memory=debug 出力および JRA 記録でモニタできます。圧縮率が高いと、ヒープの断片化を低く抑えることができますが、圧縮による休止時間が長くなります。
コマンド ライン オプション : -XXcompactSetLimit:<references>
圧縮によってオブジェクトが移動した場合は、そのオブジェクトへの参照を更新する必要があります。ガベージ コレクタは、Java スレッドが再実行できるようになる前に参照の更新を行います。更新された参照の数に比例して、ガベージ コレクションによる休止時間が長くなります。圧縮設定の制限により、圧縮領域外のオブジェクトから圧縮領域内のオブジェクトへの参照の数が決まるので、圧縮による休止時間が短縮されます。ガベージ コレクション時に、選択した圧縮領域への参照数が圧縮設定の制限を超えた場合、圧縮は取り消されます。
圧縮設定の制限は、使用されるガベージ コレクション モードによって決まり、一部のモードでは実行時に動的に調整されます。コマンド ライン オプション -XXcompactSetLimit:<references> を使用して、静的な圧縮設定の制限を指定できます。「references」には、圧縮領域内のオブジェクトへの参照の最大値を指定します。次に例を示します。
java -XXcompactSetLimit:20000 MyApplication
この設定により、圧縮設定の制限の参照数が 20000 個に設定された JVM が起動します。
詳細については、「-XXcompactSetLimit」のドキュメントを参照してください。
取り消される (中止する) 圧縮が多すぎる場合は、このオプションを使用して、圧縮設定の制限の値を大きくします。圧縮による休止時間が長すぎる場合は、制限値を小さくします。-Xverbose:memory=debug 出力と JRA 記録で圧縮の動作を、-Xverbose:gcpause=debug 出力と JRA 記録で圧縮による休止時間をモニタできます。
| 注意 : | -XXcompactSetLimit は、deterministic または pausetime ガベージ コレクション モードが使用されている場合は機能しません。これらのガベージ コレクション モードは、別のヒューリスティックを使用して圧縮による休止時間を調整するためです。 |
コマンド ライン オプション : -XXnoCompaction
圧縮を一切行わなくても長期間生存できるアプリケーションはわずかしかありませが、そのようなアプリケーションでは、圧縮を完全に無効にすることができます。
圧縮を完全に無効にするには、コマンド ライン オプション -XXnoCompaction を使用します。たとえば、次のように指定します。
java -XXnoCompaction MyApplication
詳細については、「-XXnoCompaction」のドキュメントを参照してください。
コマンド ライン オプション : -XXfullCompaction
一部のアプリケーションは、ガベージ コレクションの休止時間にあまり影響を受けないか、古いコレクションをほとんど行いません。このようなアプリケーションについては、ガベージ コレクション間のオブジェクト割り当てのパフォーマンスを最大化するために、完全な圧縮を行ったほうがよい場合があります。ただし、多数のオブジェクトが割り当てられている大きなヒープに対して完全な圧縮を行うと、処理に数秒かかることがあります。
完全な圧縮を有効にするには、コマンド ライン オプション -XXfullCompaction を使用します。たとえば、次のように指定します。
java -XXfullCompaction MyApplication
詳細については、「-XXfullCompaction」のドキュメントを参照してください。
オブジェクトの割り当て用に領域を空けるガベージ コレクションの最適化とは別に、オブジェクト割り当て自体をチューニングして、アプリケーションのスループットを最大化することができます。
コマンド ライン オプション : -XXtlaSize:min=<size>,preferred=<size> -XXlargeObjectLimit:<size> -XXminBlockSize:<size>
スレッド ローカル領域 (TLA) は、ヒープまたはナーサリに確保された空き領域のチャンクであり、スレッドに独占的に与えられます。スレッドは、別のスレッドと同期しなくても、自分専用の TLA に小規模オブジェクトを割り当てることができます。TLA に割り当てられたオブジェクトは、スレッド ローカルではありません。これらのオブジェクトは、任意のスレッドからアクセス可能であり、グローバルなガベージ コレクションの対象です。TLA が一杯になると、このスレッドは単純に新しい TLA を要求します。
スレッド ローカル領域のサイズは割り当て速度に影響しますが、ガベージ コレクションの頻度にも影響します。TLA のサイズを大きく設定すると、新しい TLA を要求する前に各スレッドが多数のオブジェクトを割り当てることができます。さらに JRockit JVM R27.2 以降では、スレッド ローカル領域に大規模オブジェクトを割り当てることが可能です。一方、TLA サイズを大きくすることで、空きメモリの小さなチャンクがオブジェクト割り当てに使用されなくなるため、断片化による影響が拡大します。JRockit JVM R27.1 以降では、TLA サイズは空き領域の利用可能なチャンクのサイズによって動的に決まるため、最少サイズから推奨サイズの間で変動します。
推奨 TLA サイズを増やすと、各スレッドが多数のオブジェクトを割り当てるアプリケーションに効果的です。二世代のガベージ コレクション方式が使用されている場合、TLA の最少サイズと推奨サイズを大きく設定すると、ナーサリ内に大規模オブジェクトを割り当てることができます。推奨 TLA サイズは、常に、ナーサリ サイズの 5% 未満です。
ガベージ コレクタは最少 TLA サイズに満たない空きチャンクを無視するため、最少 TLA サイズを大きくするとガベージ コレクションの実行時間が多少短縮されます。
推奨 TLA サイズを小さくすると、終了するまでにわずかなオブジェクトしか割り当てないスレッドを持つアプリケーションに効果的です。このようなアプリケーションは、大きな TLA サイズを一杯にできないからです。推奨 TLA サイズを小さくすると、無数のスレッドを持つアプリケーションに効果的です。このようなアプリケーションでは、ガベージ コレクションが行われる前に、スレッドが TLA を一杯にする時間がないからです。
最少 TLA サイズを小さくすると、断片化への影響が減ります。
TLA サイズは一般に、最少 TLA サイズを 2 ～ 4 KB に、推奨 TLA サイズを 16 ～ 256 KB に設定します。
TLA サイズを調整するには、コマンド ライン オプション -XXtlaSize:min=<size>,preferred=<size> を使用することもできます。次に例を示します。
java -XXtlaSize:min=1k,preferred=512k MyApplication
これにより、最少 TLA サイズが 1 KB で、推奨 TLA サイズが 512 KB に設定された JVM が起動します。
デフォルト値の詳細については、「-XXtlaSize」のドキュメントを参照してください。
| 注意 : | JRockit JVM R27.1 以前のバージョンを使用している場合、TLA サイズを調整するには、-XXlargeObjectLimit:<size> および -XXminBlockSize:<size> を最少 TLA サイズと同じ値に設定する必要があります。 |
| 注意 : | Oracle JRockit JVM R27.0 以前のバージョンを使用している場合は、最少 TLA サイズと推奨 TLA サイズを常に同じ値に設定する必要があります。TLA サイズの設定の構文は、-XXtlaSize:<size> です。 |
|