|
|
この節では、Oracle JRockit JVM の -XX コマンドライン オプションについて説明します。これらのオプションはすべて -XX で始まります。これらのオプションのなかには実装するために特定のシステム要件を満たすことが必要なものがあり、そのシステム要件が満たされていない場合は、特定のオプションが機能しないことがあります。そのため、これらのオプションは、以下の条件が満たされている場合に限って使用することをお勧めします。
| 注意 : | この節に記載されているオプションのリストは絶えず変化しています。新しく追加された -XX オプションや、非推奨になった -XX オプションを示すために、この節は必要に応じて随時改訂されます。 |
-XXaggressive は、JVM を高速で動作させて、安定した状態を早期に実現するための各種コンフィグレーションを一括して指定するオプションです。この目標を達成するために、JVM で起動時に使用される内部リソースの量は通常よりも多くなりますが、目標が実現された後は、適応性のある最適化が必要とされる頻度は低くなります。このオプションを使用する場合は、長時間継続的に実行されてメモリを大量に使用し、かつ単独で機能するアプリケーションに対象を限定して使用することをお勧めします。
| 注意 : | このオプションで行われるコンフィグレーションの内容は、リリースごとに変更される可能性があります。 |
-XXaggressive を表 3-1 に示すいずれかのパラメータと組み合わせます。
-XXagressive を opt パラメータと共に指定すると、適応性のある最適化がより早い段階で実行されるようにスケジュールが設定されて、新たな最適化が有効になります。
opt と memory をどちらも指定しない場合は、両方が指定されたものとしてアプリケーションが実行されます。
このオプションを指定するといくつかの設定が行われますが、それらの設定は、コマンドラインで -XXaggressive の後に明示的なオプションを追加することによってリセットまたは変更することができます。
このオプションを使用すると、TLA 割り当て時に TLA の参照と値をクリアし、次のチャンクをプリフェッチすることができます。整数、参照、その他が宣言されると、それらにデフォルト値の 0 または Null が設定されます (型によって異なります)。適切なタイミングで、これらの参照と値をクリアしてヒープ上のメモリを解放し、Java がそれを利用 (または再利用) できるようにする必要があります。これはオブジェクトの割り当て時に行うことも、このオプションを使用して、新しい TLA を要求するときに行うこともできます。
-XXallocClearChunks=<true | false>
これはブール型のオプションで、一般に IA64 システムで推奨される方法です。最終的には、オプションの使用法はアプリケーションによって異なります。クリアするチャンクのサイズを設定する場合は、このオプションを -XXallocClearChunkSize と組み合わせて使用します。
デフォルトでは、この機能は無効になっています。ブール値を指定せずにこのオプションを使用した場合、デフォルトは true になります。
この機能はデフォルトで無効になっていますが、IA64 システムでは aggressive:memory によって有効に設定される機能の 1 つです。
-XXallocClearChunkSize と共に使用して、クリアするチャンクのサイズを設定します。
形式 : -XXallocClearChunks -XXallocClearChunkSize=<size>[k|K][m|M][g|G]
このオプションを -XXallocClearChunks と組み合わせて、クリアするチャンクのサイズを設定します。
java -XXallocClearChunks -XXallocClearChunkSize=256m myApp
値を指定せずにこのオプションを使用した場合、デフォルト値は 512 バイトになります。
-XXallocClearChunks と組み合わせた場合の機能については、「使用法」を参照してください。
-XXallocClearChunks が使用されていない場合、このオプションを使用することもできません。
このオプションを指定すると、スレッドローカル領域がチャンクに分割され、新しいチャンクが使用された時点で、その次のチャンクがプリフェッチされます。
| 注意 : | Intel Xeon サーバでこの機能の効果を十分に上げるには、コンピュータの BIOS でハードウェア プリフェッチを無効にすることをお勧めします。 |
形式 : -XXallocPrefetch[=true|false]
有効にするには : java -XgcPrio:pausetime -XXallocPrefetch myApp
無効にするには : java -XgcPrio:pausetime -XXallocPrefetch=false myApp
ほとんどのプラットフォームにおいてこの機能はデフォルトで有効になっています。
このオプションは、-XXallocRedoPrefetch を使用する場合にも設定する必要があります。
このオプションを指定すると、新しいチャンクが使用された時点でプリフェッチされるチャンクが 1 つ多くなります (後続の 2 つのチャンクがプリフェッチされるようになります)。
| 注意 : | Intel Xeon サーバでこの機能の効果を十分に上げるには、コンピュータの BIOS でハードウェア プリフェッチを無効にすることをお勧めします。 |
形式 : -XXallocRedoPrefetch[=true|false]
有効にするには : java -XXallocPrefetch -XXallocRedoPrefetch myApp
無効にするには : java -XXallocPerfetch -XXallocRedoPrefetch=false myApp
ほとんどのプラットフォームにおいてこの機能はデフォルトで有効になっています。
-XXallocPrefetch を設定しないと、このオプションは機能しません。
このオプションはコードの最適化のために、呼び出しのプロファイリングの使用を有効化します。プロファイリングでは、アプリケーションに固有の有用な実行時統計を記録します。多くの場合、JVM がその統計を実行するためにパフォーマンスが向上します。
| 注意 : | このオプションは JRockit JVM R27.3.0 以降のバージョンでサポートされています。今後のバージョンではデフォルトになる場合があります。 |
java -XXcallProfiling myApp
このオプションはデフォルトで無効になっています。使用するには、有効化する必要があります。
このオプションでは、圧縮率を設定します。圧縮は、断片化を回避するためにガベージ コレクタが用いる主な手段です。ヒープの一部を調べて、その部分で生存しているすべてのオブジェクトを寄せ集め、連続する空き領域を拡大するという仕組みです。JVM がヒープを圧縮している間は、オブジェクトがあちこちに移動するので、オブジェクトにアクセスするすべてのスレッドを停止させる必要があります。したがって、休止時間を減らすためにヒープの一部だけが圧縮されます。
ガベージ コレクションに時間がかかりすぎるときは、圧縮領域を減らして休止時間を短くすると有効な場合があります。あるいは、特に非常に大きい配列を割り当てているときには、圧縮領域を増やしてヒープ上の断片化を減らし、それによって割り当てを高速化することが必要になる場合があります。
| 注意 : | 現在の JRockit JVM では動的な圧縮が行われるため、-XXcompactRatio の指定が必要な場合はほとんどありません。 |
圧縮率 ([nn]) をヒープのサイズに対するパーセントで指定します。
500MB のヒープで上の指定を行うと、ガベージ コレクタはガベージ/古いコレクションごとにヒープの 50MB を圧縮します。
静的な圧縮を実行している場合、デフォルトは約 6% です。ただし、静的な圧縮を使用していない場合は、実行の開始時にのみデフォルトが適用されます。
-XXcompactRatio を使用すると、以下のような特定のオプションに影響を与えます。
-XgcPrio:deterministic または -XgcPrio: pausetime の実行中に -XXcompactRatio を設定すると、不定の休止時間が発生することがある。-XXfullCompaction は -XXcompactRatio:100 と同等であり、お互いをオーバーライドする。-XXthroughputCompaction と一緒に使用してはならない。
-XXcompactRatio を使用する場合は、以下の例外に注意してください。
-XXcompactRatio を -XXnoCompaction と一緒に使用することはできない。-XXcompactRatio、-XXinternalCompactRatio、および -XXexternalCompactRatio を同時に 3 つ設定することはできない。この中の 2 つのオプションを同時に設定することはできます。
このオプションでは、圧縮領域内のオブジェクトへの参照の最大数を設定します。
圧縮とは、Java ヒープ内で生存しているオブジェクトを寄せ集めて空き領域を拡大し、大きなオブジェクトの割り当てに利用できるようにする処理のことです。JRockit JVM はガベージ コレクションごとに Java ヒープの小さな部分を圧縮します。圧縮された領域内のオブジェクトへの参照は、「圧縮セット」に格納されます。非確定的ガベージ コレクションを実行しているときは、圧縮領域への参照の数が圧縮の休止時間に影響を与えます。このオプションを使用すると、圧縮セットのサイズを制限し、それによって圧縮の休止時間をある程度制限することができます。
形式 : -XXcompactSetLimit:<size>
java-XXcompactSetLimit:10000myApp
このコマンドでは、圧縮セットで圧縮領域内のオブジェクトへの参照を 10,000 に制限します。
デフォルトの制限は動的な値です。デフォルトの初期値は、ガベージ コレクタとリリースに応じて異なります。表 3-2 にデフォルト値を示します。
-XcompactSetLimit を使用する場合は、以下の例外に注意してください。
| 警告 : | これは高度なチューニング オプションです。このオプションの機能を理解していて、不適切な使用によって弊害が生じても十分に対処可能な場合以外は、このオプションは使用しないでください。 |
このオプションでは、圧縮領域内の単一のオブジェクトへの参照の最大数を設定します。いずれかのオブジェクトへの参照の数が、このオプションで指定された値を超えている場合、圧縮中にそのオブジェクトの移動は行われません。
圧縮とは、Java ヒープ内で生存しているオブジェクトを寄せ集めて空き領域を拡大し、大きなオブジェクトの割り当てに利用できるようにする処理のことです。JRockit JVM はガベージ コレクションごとに Java ヒープの小さな部分を圧縮します。圧縮中にオブジェクトを移動する際は、そのオブジェクトへの参照を更新する必要があります。そのため、被参照数の多いオブジェクトの移動は、被参照数がわずかなオブジェクトの移動よりもコストの高い処理となります。
形式 : -XXcompactSetLimitPerObject:<size>
java-XXcompactSetLimitPerObject:500myApp
このコマンドは、圧縮対象となるオブジェクトへの参照数をオブジェクト 1 つあたり 500 に制限します。
以下のいずれかのオプションが設定されている場合のみ、このオプションも使用できます。
-XgcPrio:deterministic-Xgcprio:pausetime-XXusePointerMatrix
このフラグは、圧縮された参照の使用を制御し、ヒープに格納されるすべてのポインタを 32 ビットに制限します。圧縮された参照を使用すると Java ヒープ リソースの使用量が削減され、メモリ バスで転送されるデータの量も減少するため、パフォーマンスが向上します。また、このオプションを指定すると、参照が圧縮されていない場合には使用済みとなって利用できないおそれがあるヒープ上の領域を解放することになるので、このオプションはその意味でも有益です。
形式 : -XXcompressedRefs[=[true|1|false|0]]
java -XgcPrio:pausetime-XXcompressedRefs=truemyApp
java -XgcPrio:pausetime-XXcompressedRefs=0myApp
-XXcompressedRefs を指定しない場合、ヒープ サイズが 4GB 未満であれば、すべての 64 ビット マシンで参照の圧縮が有効になります。ヒープ サイズは通常、-Xmx フラグを使用して制御されます。
| 注意 : | JRockit JVM R26.4 以前では、参照の圧縮はデフォルトで無効になっています。 |
-XXcompressedRefs によって、他のコマンドライン オプションが以下のような影響を受けます。
このオプションでは、Java のファット ロック スピン コードを無効にし、ファット ロックを取得しようとしてブロックされたスレッドが直接スリープ状態に入れるようにします。
Java のオブジェクトは、いずれかのスレッドがそのオブジェクト上で同期ブロックに入るとすぐにロックになります。すべてのロックは、ロックしているスレッドが解放するまで保持されます (つまりロックされたままになります)。ロックがすぐに解放されないと、ロックは「ファット ロック」に引き上げられることがあります。「スピン」は、特定のロックを必要としているスレッドが、タイトなループの中でスピンしながら、そのロックがまだ取得されているかどうかを継続的にチェックするときに発生します。ファット ロックに対するスピンは一般に効果がありますが、場合によっては負荷をかけて、パフォーマンスに影響を与えることがあります。-XXdisableFatSpin を使用すると、ファット ロックに対するスピンを無効にし、パフォーマンスへの潜在的な影響を排除することができます。
このオプションは、ガベージ コレクタ方式の変更を無効にします。圧縮ヒューリスティックおよびナーサリ サイズ ヒューリスティックは、このオプションの影響を受けません。
デフォルトでは、ガベージ コレクション ヒューリスティックが有効になります。
R27.5 よりも前のリリースでこのオプションを使用するには、-XgcPrio:throughput または -XgcPrio:pausetime が使用されている必要があります。-Xgc または -XXsetGC の場合は機能しません。-XgcPrio:throughput はデフォルトです。
JRockit JVM R27.5 以降のリリースでも、このオプションは、静的コンカレント ガベージ コレクションのパラレル マークまたはスイープへの一時的な方式変更を無効にします。
通常、JRockit JVM がクラッシュするとプロセスの状態 (コア ダンプと呼ばれる) が保存されますが、ヒープはこの状態から除外されます。ヒープはサイズが大きく、大量のディスク領域を占有するからです。このオプションを使用すると、ヒープを含むすべてのプロセスの状態が保存されます。ディスク領域の使用量は増えますが、コア ダンプを使用して、クラッシュを引き起こした問題の原因を突き止めるのがはるかに容易になります。このオプションを使用すると、大量の情報がディスクに保存されます。-XXdumpFullState によって保存されるすべての情報を保存すると情報量が多すぎて望ましくない場合は、-XXdumpSize:normal を使用してください。
-XXdumpFullState は、-XXdumpsize:large と同等です。詳細については、「-XXdumpSize」を参照してください。
このオプションを使用すると、ダンプ ファイルを生成し、そのファイルの相対的なサイズ (小、中、大) を指定することができます。
このコマンドを表 3-3 に示すいずれかのパラメータと共に使用して、ダンプ ファイルの相対的なサイズを指定します。
メモリ不足エラーが最初に発生した時点で JRockit JVM を終了させます。メモリ不足エラーを処理するよりも、JRockit JVM のインスタンスを再起動する方が望ましい場合に利用できます。
起動時にこのコマンドを入力し、メモリ不足エラーが最初に発生した時点で JRockit JVM を終了させます。
このオプションでは、外部圧縮 (「退避」) 中に圧縮するヒープ パーツの数を設定します。
| 注意 : | -XXheapParts コマンドライン オプションを使用すると、ヒープ パーツの総数を変更できます。 |
形式 : -XXexternalCompactRatio=nn
java -XXexternalCompactRation=12 myApp
デフォルトで圧縮するパーツの数は -XgcPrio:throughput の場合は 8 です。その他すべてのガベージ コレクションのモードでは動的です。
このオプションを -XgcPrio または -XXthroughputCompaction と共に使用すると、動的な圧縮ヒューリスティックの一部が無効になるため、パフォーマンスに影響が生じることがあります。
-XXexternalCompactRatio を使用する場合は、以下の例外に注意してください。
-XXexternalCompactRatio を以下のいずれかのオプションと一緒に使用することはできない。-XXcompactRatio-XXinternalCompactRatio-XXexternalCompactRatio
-XXfullCompaction を使用すると、常に完全圧縮が行われ、古いコレクションごとにヒープ全体が圧縮されるようになります。圧縮とは、Java ヒープ内で生存しているオブジェクトを寄せ集めて空き領域を拡大し、大きなオブジェクトの割り当てに利用できるようにする処理のことです。デフォルトでは、JRockit JVM はガベージ コレクションごとに Java ヒープの小さな部分を圧縮します。完全圧縮を行うと、ヒープの断片化が最小限に抑えられることによりアプリケーションのスループットが向上しますが、圧縮時のガベージ コレクションの休止時間が非常に長くなる場合があります。
起動時にこのコマンドを入力し、完全圧縮を指定します。完全圧縮を確実に行うには、これが唯一の方法です。
-XXfullCompaction を使用する場合は、以下の例外に注意してください。
-XXfullCompaction を設定するのは、-XXcompactRatio:100 を設定するのと同じ。 -XXthroughputCompaction と一緒に使用してはならない。
-XXfullCompaction を以下のいずれかのオプションと一緒に使用することはできません。
このオプションを使用すると、System.gc() が呼び出されるたびに、ガベージ コレクタが完全なガベージ コレクションを行います。完全なガベージ コレクションでは、古い領域のコレクションやソフト参照の解除も行われます。Java からガベージ コレクションを明示的に呼び出すたびに、ガベージ コレクタで最大限のガベージ コレクションを行いたい場合に、このオプションを使用します。
このオプションは、デフォルトのガベージ コレクタでは十分なメモリが解放されない場合に役立ちます。ただし、ガベージ コレクションの休止時間が長くなることがあります。
このオプションを使用すると、System.gc() の呼び出し時に古い領域のコレクションがすでに実行されている場合は、そのコレクションが終了するのを待ってから、新しい古い領域のコレクションがトリガされます。-XXfullSystemGC では、ソフト参照されているすべてのオブジェクトが解放されます。
-XXfullSystemGC を -XXnoSystemGC と一緒に使用することはできません。
このオプションでは、ガベージ コレクタが使用するガベージ コレクション スレッドの数を指定します。このオプションはパラレルのナーサリ コレクタとパラレルの古い領域コレクタの両方に適用されるだけでなく、コンカレント コレクタと確定的コレクタにも適用されます。
java -XgcPrio:pausetime-XXgcThreads:4myApp
このコマンドは、パラレル フェーズにおいてガベージ コレクタが使用できるガベージ コレクション スレッドの数として「4」を設定します。
デフォルトでは、これらの値はマシンのコアの数およびハードウェア スレッドの数に基づいて決められます。
このオプションが有効なのは JRockit JDK 5.0 P26.0.0 以降および JRockit JDK 5.0 R26.4.0 以降のみです。
このオプションを使って、ヒープの空き領域がどこまで減った時点でコンカレント ガベージ コレクションを開始するかを設定できます。コンカレント ガベージ コレクション中にヒープが一杯になると、ガベージ コレクションが一部のヒープ領域を解放するまで Java アプリケーションはメモリを割り当てることができません。このため、アプリケーションが休止状態になることがあります。ヒープが一杯にならないようにトリガ値は実行時に自動的にチューニングされますが、この自動のチューニングに時間がかかりすぎることがあります。この機能に頼らずに、-XXgcTrigger を使って、ガベージ コレクションのトリガ値をアプリケーションに適した値に最初から設定できます。
コンカレント マーク フェーズの途中でヒープが一杯になると、スイープ フェーズはパラレル スイープに戻ります (-XXnoParSweep を指定した場合を除く)。この動作が頻繁に起こり、これを回避するためにガベージ コレクションのトリガ値が自動的に増えない場合、-XXgcTrigger を使ってガベージ コレクションのトリガ値を手動で増やしてください。
nn は、ガベージ コレクションがトリガされたときに使用できる空きヒープの量を、ヒープ全体に占める割合で表す値です。
java -XXgcTrigger:50 myApp
このオプションを設定すると、JRockit JVM は、空き状態で残っているのがヒープの 50% (たとえば 1 GB のヒープなら約 512 MB) となったときにガベージ コレクションをトリガします。ガベージ コレクションの現在のトリガ値は、トリガが変更されるたびに -Xverbose:memdbg の出力に表示されます。
-XXgcTrigger が指定されていない場合、システムは自動的に適切なパーセンテージ値を見つけようとします。-XXgcTrigger:nn が指定されていると、代わりにこちらが使用され、自動プロセスの関与はありません。
たとえば、コマンドラインで -Xgc:singlepar または -Xgc:genpar を指定して、ガベージ コレクタがパラレル マークとパラレル スイープの両方を実行している場合、ガベージ コレクタは -XXgcTrigger 値を無視します。
このオプションでは、ヒープ パーツの数を指定の静的な値に設定します。
デフォルトのヒープ パーツの数は 128 です。ヒープ パーツの数は実行時に増やすことができます。
-XXexternalCompactRatio および -XXinternalCompactRatio のオプションでは、単位としてヒープ パーツが使用されます。そのため、ヒープ パーツの数の変更は、これらのオプションの設定の仕方に影響を及ぼします。
このオプションでは、HotSpot ディテクタでソフトウェア的なサンプリングを行う代わりに、ハードウェアのパフォーマンス カウンタを使用し、最適化を推し進めます。ハードウェアのパフォーマンス カウンタを使用すると、ホットスポット サンプリングの精度が高くなり、パフォーマンスが向上します。このオプションはデフォルトで無効になっています。
このオプションは、Itanium 上の Red Hat 4.0 および SUSE 9.0 で利用できます。
| 警告 : | これは高度なチューニング オプションです。このオプションの機能を理解していて、不適切な使用によって弊害が生じても十分に対処可能な場合以外は、このオプションは使用しないでください。 |
このオプションでは、ポインタ マトリックスの各「行」の初期サイズを設定します。ポインタ マトリックスは参照を格納するためのデータ構造で、-XgcPrio:deterministic または -XgcPrio:pausetime が使用されている場合、または -XXusePointerMatrix が設定されている場合の圧縮中に使用されます。ポインタ ベクトルの初期サイズを増やすと JRockit JVM のメモリ占有量が増加しますが、それによってアプリケーションのスループットが向上する場合もあります。
形式 : -XXinitialPointerVectorSize:<size>
java-XXinitialPointerVectorSize:40myApp
このコマンドは、ポインタ ベクトルの初期サイズを 40 参照に設定します。
このオプションが有効なのは、-XgcPrio:deterministic または -XgcPrio:pausetime のどちらかが使用されている場合、または -XXusePointerMatrix が設定されている場合のみです。
| 注意 : | -XXheapParts コマンドライン オプションを使用すると、ヒープ パーツの総数を変更できます。 |
形式 : -XXinternalCompactRatio=nn
java -XgcPrio:throughput -XXinternalCompactRatio=12 myApp
このコマンドは、圧縮するヒープ パーツの数を 12 に設定します。このコマンドは -XgcPrio:throughput と共に使用されているので、デフォルト値の 8 パーツはオーバーライドされます。
デフォルトで圧縮するパーツの数は -XgcPrio:throughput の場合は 8 です。その他すべてのガベージ コレクションのモードでは動的です。
このオプションを -XgcPrio または -XXthroughputCompaction と共に使用すると、動的な圧縮ヒューリスティックの一部が無効になるため、パフォーマンスに影響が生じることがあります。
-XXinternalCompactRatio を使用する場合は、以下の例外に注意してください。
-XXinternalCompactRatio を以下のいずれかのオプションと一緒に使用することはできない。-XXcompactRatio-XXinternalCompactRatio-XXexternalCompactRatio
このオプションでは、JRA の記録を有効にします。JRA の記録は、実行中の JRockit JVM インスタンスに関する統計を取得するための方法です。
| 注意 : | このコマンドは、JRockit JVM 1.4.2_04 から追加されました。それ以前は、表 3-4 に示すように、コマンドの組み合わせごとに別々のコマンドを使用する必要がありました。 |
形式 : 形式は、使用する JRockit JVM のバージョンによって異なります。
-XXjra コマンドを表 3-4 の「JRockit 1.4.2_04 以降」に示すパラメータと共に使用する。次に例を示します。-XXjra:delay-XXjraDelayjava-XXjra:delay=10,recordingtime=100,filename=jrarecording2.xmlmyApp
JRockit JVM 1.4.2_03 以前でリリースされたバージョンの JRA でこれと同じデータを作成するには、以下の 3 つのオプションを指定する必要があります。
コマンドラインに複数の -XXjra オプションを追加しません。追加すると、最終的なもの以外のすべての -XXjra オプションを廃棄します。たとえば、以下を入力すると
java -XXjra:filename=apa.jra -XXjra:delay=10 -XXjra:time=11 Hello
java -XXjra:time=11 Hello
これはそのつど XXjra が解析され、デフォルト値がリセットされてからこの引数に与えられたサブ引数が解析、設定されるからです。代わりに、あなたが最初の例から期待する結果を取得するために、以下を入力してください。
java -XXjra:filename=apa.jra,delay=10,time=11 Hello
このオプションは、ナーサリ内の保持領域のサイズをナーサリに対する割合として設定します。この保持領域は、新しく割り当てられたオブジェクトが早期に古い領域にプロモートされることを防ぎます。
| 注意 : | このオプションは、JRockit JVM R27.3 以降のリリースでのみ使用できます。 |
形式 : -XXkeepAreaRatio:<percentage>
java-XXkeepAreaRatio:10myApp
保持領域のサイズをナーサリ サイズの 10% に設定します。
デフォルトの保持領域はナーサリ サイズの 25% です。保持領域はナーサリ サイズの 50% を越えることはできません。
保持領域の割合は、ガベージ コレクタが世代別である場合のみ有効です。
このオプションでは、オブジェクトを (メモリ管理の面で) 「大きい」と見なすサイズを設定します。この制限よりも大きいオブジェクトは、大きなオブジェクトと見なされ、TLA 内には割り当てられません。これらはデフォルトの制限で、-XXlargeObjectLimit:nn を使って変更できます。これらの制限は、JRockit JVM 1.4.2 以降にのみ適用されます。
形式 : -XXlargeObjectLimit:<size>[k|K][m|M][g|G]
-XXlargeObjectLimit をメモリ値および単位 (<value><unit>) と組み合わせます。
java-XXlargeObjectLimit:6KmyApp
このコマンドでは、大きなオブジェクトの制限が 6KB に設定されます。大きなオブジェクトの制限に最小値や最大値はありません。
値を指定しない場合、デフォルトで、TLA の最小サイズ、および TLA の優先サイズを 2 で割った値のうち、小さい方の値に設定されます。
TLA の最小サイズや優先サイズを設定した場合、大きなオブジェクトの制限と最小ブロック サイズ (-XXminBlockSize で設定) は、必要に応じて、JRockit JVM により自動的に調整されることがあります。TLA の最小サイズと優先サイズ、大きなオブジェクトの制限、最小ブロック サイズの間で、常に次のような関係が維持されます。
-XXlargeObjectLimit <= -XXtlaSize:min <= -XXminBlockSize
-XXtlaSize:min <= -XXtlaSize:preferred
これらのオプションを複数設定する場合は、使用する値がこれらの条件を満たしていることを確認してください。
大きなオブジェクトの制限や最小ブロック サイズを JRockit JVM で必要に応じて自動的に調整する場合、メモリ管理のチューニングのため、TLA サイズのパラメータを主に設定することをお勧めします。
なし
これは、Java ヒープや JVM の他の領域に、可能であればラージ ページを使用するように JRockit JVM に指示する古いオプションです。ラージ ページを使用すると、アプリケーションでプロセッサ内の TLB (Translation Look-aside Buffer) をより効果的に利用できるようになります。
| 注意 : | このオプションはもはや、ラージ ページを有効にするための優先的なオプションではありません。代わりに、-XlargePages を使用してください。 |
-XXlazyUnlocking が設定されていると、重要なセクションの実行が終了してもその時点ではロックは解放されません。そのため、ロックが一度取得された後で、次にそのようなロックを取得しようとするスレッドは、そのロックがすでに解放されているか、または解放可能であることを確認する必要があります。この確認は、最初のスレッドがその時点でまだロックを使用し続けているかどうかを調べることによって行われます。共有ロックは通常のロックに変換され、遅延モード (lazy モード) の状態は継続しません。
java-XXlazyUnlockingmyApp
この例は、JRockit JVM R27.4 以降のリリースで遅延ロック解除を有効にします。
R27.5 の形式 : -XXlazyUnlocking:enable=<true|false>
java-XXlazyUnlocking:enable=falsemyApp
この例は、JRockit JVM R27.5 で遅延ロック解除を無効にします。
R27.5 の遅延ロック解除は、IA64 を除くすべてのプラットフォーム上の Java SE 6 バージョンの JRockit JVM、および確定的ガベージ コレクション モードを除くすべてのガベージ コレクション モードでデフォルトで有効になっています。
R27.5 よりも前のリリースでは、遅延ロック解除はデフォルトで無効になっています。
このオプションの使用対象として想定されているのは、非共有ロックを多用するアプリケーションです。多数の共有ロックを使用するアプリケーションでは、それらのロックの生存期間が短い場合でも、このオプションを設定するとパフォーマンスの低下を招くことがあるので注意が必要です。
| 警告 : | これは高度なチューニング オプションです。このオプションの機能を理解していて、不適切な使用によって弊害が生じても十分に対処可能な場合以外は、このオプションは使用しないでください。 |
このオプションでは、ガベージ コレクション間にプールされるラージ ポインタ ベクトルの最大サイズを設定します。ポインタ ベクトルとは、参照を格納するために使用される「ポインタ マトリックス」データ構造の各行のことです。このポインタ マトリックスは、-XgcPrio:deterministic または -XgcPrio:pausetime が使用されている場合、または -XXusePointerMatrix が設定されている場合の圧縮中に使用されます。プールされるポインタ ベクトルの最大サイズを増やすと JRockit JVM のメモリ占有量が増加しますが、それによってアプリケーションのスループットが向上する場合もあります。
形式 : -XXmaxPooledPointerVectorSize:<size>
java-XXmaxPooledPointerVectorSize:8000myApp
プールされるラージ ポインタ ベクトルの最大サイズを 8,000 に設定します。
このオプションが有効なのは、-XgcPrio:deterministic または -Xgcprio:pausetime のどちらかが使用されている場合、または -XXusePointerMatrix が設定されている場合のみです。
このフラグを設定すると、mixed mode Java 実行機能 (MME) が有効になります。この機能は、64 ビット Intel Itanium Linux システムでサポートされます。この機能によって、32 ビット IA-32 JNI ネイティブ コードが含まれる Java アプリケーションを、Intel Itanium プラットフォームでそのまま実行できます。
mixed mode Java 実行を有効にするには、次のコマンドを入力します。
java-XXmmemyApp
-XXmme を指定しない場合、mixed mode Java 実行機能は無効です。
この機能は、64 ビット Intel Itanium システムでのみ使用できます。現在サポートされているオペレーティング システムは、Intel IA-32 Execution Layer v6 以降がインストールされている Red Hat Enterprise Linux 4 Update 4 だけです。
-XXminblocksize では、最小ブロック サイズを設定します。これはフリーリストに戻される最小メモリ領域です。したがって、このオプションではフリーリスト上の利用可能な最小メモリ チャンクを設定することになります。
| 注意 : | このオプションは、ブロック サイズを設定する上で必ずしも最良の方法ではありません。ほとんどの場合は、-XXtlaSize を使用した方が良い結果が得られます。 |
形式 : -XXminBlockSize:<memSize>
<memSize> は、フリーリストに戻されるメモリ領域のサイズです。
ガベージ コレクションとオブジェクト割り当ての速度を上げるために、JVM は最小ブロック サイズより小さい空きチャンクを無視します。最小ブロック サイズより小さい空きチャンクをオブジェクト割り当てに使用することはできません。このような空きチャンクは「Dark matter」と呼ばれます。Dark matter は無駄なヒープ メモリです。最小ブロック サイズを増やすと、大きなオブジェクトの割り当てが高速になり、ガベージ コレクションの速度が上がることがありますが、Dark matter の量も増える可能性があります。Dark matter の量が増えると、ガベージ コレクションの回数が増加します。
-XXlargeObjectLimit、-XXtlaSize、および -XXminBlockSize のうち、2 つ以上を設定する場合は、次の関係を満たしている必要があります。
-XXlargeObjectLimit <= -XXtlaSize <= -XXminBlockSize
値を指定しない場合、デフォルトで、TLA の最小サイズ、および TLA の優先サイズを 2 で割った値のうち、小さい方の値に設定されます。
TLA の最小サイズや優先サイズを設定した場合、大きなオブジェクトの制限 (-XXlargeObjectLimit で設定) と最小ブロック サイズは、JRockit JVM により自動的に調整されることがあります。
TLA の最小サイズと優先サイズ、大きなオブジェクトの制限、最小ブロック サイズの間で、常に次のような関係が維持されます。
-XXlargeObjectLimit <= -XXtlaSize:min <= -XXminBlockSize
-XXtlaSize:min <= -XXtlaSize:preferred
これらのオプションを複数設定する場合は、使用する値がこれらの条件を満たしていることを確認してください。
大きなオブジェクトの制限や最小ブロック サイズを JRockit JVM で必要に応じて自動的に調整する場合、メモリ管理のチューニングのため、TLA サイズのパラメータを主に設定することをお勧めします。
なし
ガベージ コレクション時の圧縮を無効にします。圧縮とは、Java ヒープ内で生存しているオブジェクトを寄せ集めて空き領域を拡大し、大きなオブジェクトの割り当てに利用できるようにする処理のことです。圧縮を無効にすると、ガベージ コレクションの休止時間が短縮されることがありますが、Java ヒープで断片化が発生してアプリケーションのスループットが低下することもあります。また、最悪の場合、OutOfMemoryError が送出される場合があります。
ガベージ コレクション時は常に、少なくとも部分圧縮が行われます。圧縮なしでアプリケーションが耐えられるという想定で、圧縮を一切行わないようにしたい場合は、起動時にこのコマンドを使って圧縮を無効にする必要があります。
このオプションでは、JRockit JVM を通じた JIT によるインライン化を無効にします。「JIT によるインライン化」では、コード パイプラインで呼び出しが出現するとすぐに、呼び出しが小さいメソッドにインライン化されます。
| 注意 : | このオプションを使用すると、パフォーマンスが多少低下します。 |
このオプションは、必ず -XnoOpt と組み合わせて使用してください。-XXnojitinline は、メソッドが最初にコンパイルされるときだけインライン化を無効にします。一緒に -XnoOpt を設定しなければ、コードが最適化されるときにメソッドがインライン化される可能性があります。
このオプションは、System.gc() の呼び出しによってガベージ コレクションが開始されないようにします。アプリケーションで System.gc() を使用していて、コレクションを実行するタイミングをガベージ コレクタ自体に判断させたい場合は (デフォルトの動作)、このオプションを使用します。このオプションは、デバッグを行うときに役立ちます。また、不必要なガベージ コレクションが行われなくなるので、パフォーマンスが向上する場合もあります。
起動時に上記の形式でコマンドを入力します。このオプションを使用すると、場合によってはガベージ コレクションの休止時間が長くなることがありますが、一般にはアプリケーションのパフォーマンスが向上します。
また、このオプションを使用した場合としない場合では、-XXprintSystemGC で出力される情報が異なります。
-XXnoSystemGC を -XXfullSystemGC と一緒に使用することはできません。
このオプションでは、最適化メソッドで使用するスレッドの数を JVM に対して指示します。最適化メソッドの処理はバックグラウンドで実行されます。
形式 : -XXoptThreads:<# threads>
java -XgcPrio:pausetime-XXoptThreads:3myApp
このコマンドは、JVM に対して、最適化メソッド用に 3 つのスレッドを使用するように指示します。
-XXoptThreads が指定されていない場合は、最適化メソッド用に 1 つのメソッドが使用されます。
このオプションが有効なのは JRockit JVM 5.0 P26.0.0 以降および JRockit JVM 5.0 R26.4.0 以降のみです。
| 警告 : | これは高度なチューニング オプションです。このオプションの機能を理解していて、不適切な使用によって弊害が生じても十分に対処可能な場合以外は、このオプションは使用しないでください。 |
このオプションでは、ポインタ マトリックスのリニア シーク距離を設定します。ポインタ マトリックスは参照を格納するためのデータ構造で、-XgcPrio:deterministic または -XgcPrio:pausetime が使用されている場合、または -XXusePointerMatrix が設定されている場合の圧縮中に使用されます。リニア シーク距離を減少させると JRockit JVM のメモリ占有量が増加しますが、それによってアプリケーションのスループットが向上する場合もあります。
形式 : -XXpointerMatrixLinearSeekDistance:<distance>
java -XXpointerMatrixLinearSeekDistance:5 myApp
このオプションが機能するのは、-XgcPrio:deterministic または -XgcPrio:pausetime が使用されている場合、または -XXusePointerMatrix が設定されている場合のみです。
このオプションを使用すると、ガベージ コレクションを要求しているスレッドのスレッド ID が出力されます。このオプションを通じて、System.gc() が呼び出される頻度に関する情報を取得できます。-XXnoSystemGC を使用した場合は、出力される情報が変わります。-XXnoSystemGC を使用すると、スレッド ID が出力されません。System.gc() が呼び出されたが、要求が拒否されたことを示す情報が表示されるだけです。
上記のようにこのオプションを入力すると、System.gc() が呼び出されるたびにスレッド ID が出力されます。
このオプションでは、動的なガベージ コレクタを無効にし、いずれかの静的なガベージ コレクタを設定します。静的な動作と作業負荷を伴うアプリケーションでは、動的なガベージ コレクタよりも静的なガベージ コレクタを使用する方が有利な場合があります。そのような場合に、このオプションが役立ちます。このオプションは
-Xgc
よりも多くのガベージ コレクタのモードを提供します。
形式 : -XXsetGC:[gen/single|par/con|par/con] myApp
パラレルまたはコンカレント マークを行い、パラレル スイープまたはコンカレント スイープを使用する世代別またはシングル スペースのガベージ コレクタを選択できます。
二世代のガベージ コレクションでは、ヒープが 2 つのセクション、つまり、古い世代と若い世代 (ナーサリ) に分割されます。オブジェクトがナーサリに割り当てられて、ナーサリが一杯になると、JVM はすべての Java スレッドを停止し、生存しているオブジェクトを若い世代 (ナーサリ) から古い世代に移動します。
ガベージ コレクションのシングル スペース オプションの場合、すべてのオブジェクトは、経過時間に関係なく、ヒープ上の 1 つの領域内で生存期間を過ごします。つまり、シングル スペース ガベージ コレクタにはナーサリはありません。
コンカレント ガベージ コレクション アルゴリズムでは、マークとスイープを他のすべての処理と「コンカレント」(同時) に行う。つまり、Java スレッドを停止せずに完全なガベージ コレクションを行う。
パラレル ガベージ コレクション アルゴリズムでは、ヒープが一杯になったときに Java スレッドを停止し、すべての CPU を使ってヒープ全体の完全なマーク アンド スイープを行います。パラレル ガベージ コレクタではコンカレント ガベージ コレクタよりも休止時間が長くなりますが、アプリケーションのスループットが最大になります。このようにパフォーマンスが最大になるため、アプリケーションで長い休止時間を許容できる場合は、シングル CPU マシン上でもパラレル ガベージ コレクタをお勧めします。
java-XXsetGC:genparconmyApp
このコマンドでは、パラレル マーク アルゴリズムとコンカレント スイープ アルゴリズムを使用する世代別 (2 つの領域の) ガベージ コレクションを設定します。
java-XXsetGC:singleconparmyApp
このコマンドでは、コンカレント マーク アルゴリズムとパラレル スイープ アルゴリズムを使用するシングル スペース ガベージ コレクションを設定します。
| 警告 : | このオプションは、ガベージ コレクション方式ごとの効果の違いを理解している場合にのみ使用してください。
-Xgc から提供されたガベージ コレクタのモードは大部分のアプリケーションに対応します。 |
-XXsetGC を指定すると、以下のオプションが影響を受けます。
-XXsetGC を設定すると、-Xgc がオーバーライドされる。逆についても同様です。-XsetGC を設定すると、-server および -client の効果の一部がオーバーライドされる。
-XXsetGC を使用する場合は、以下の例外に注意してください。
このオプションでは、静的な圧縮率を設定し、圧縮領域を選択するための単純な「スライディング ウィンドウ」ヒューリスティックを設定します。
圧縮とは、Java ヒープ内で生存しているオブジェクトを寄せ集めて空き領域を拡大し、大きなオブジェクトの割り当てに利用できるようにする処理のことです。JRockit JVM で使用される部分圧縮では、ガベージ コレクションごとに Java ヒープの小さな部分だけが圧縮されます。圧縮領域のサイズと位置を選択するデフォルトのヒューリスティックでは、圧縮の休止時間を均等に保つようになっています。アプリケーションが休止時間による影響を受けにくい場合は、静的な圧縮領域のサイズを設定し、単純な「スライディング ウィンドウ」で圧縮領域を選択することにより、パフォーマンスが向上する可能性があります。
圧縮は「スライディング ウィンドウ」方式で行われます。つまり、ガベージ コレクションのたびにヒープの一部だけが圧縮されていきます。各ガベージ コレクションで圧縮されるヒープの量は、-XXcompactRatio を使って指定できます。デフォルトでは、ガベージ コレクションのたびにヒープの約 6%、つまり 8/128 ずつ圧縮されます。つまり、最初のガベージ コレクションでは 1 ～ 8 の部分が圧縮され、2 回目のガベージ コレクションでは 9 ～ 16 の部分が圧縮されます。それ以降も同様です。 120 ～ 128 の部分の圧縮が終わると、「ウィンドウ」は再び 1 ～ 8 の部分から始まります。静的モードの圧縮タイプは外部 (退避) です。
-XXcompactRatio を使用して、圧縮領域のサイズを指定できます。
-XstaticCompaction を使用する場合は、以下の例外に注意してください。
このオプションを指定すると、ヒープ内の実データの割合に基づいて圧縮率が動的に調整されるようになります。このオプションは高い配分率にもかかわらず、実データの低比率であるアプリケーションに対してのアプリケーション スループットを改良できます。
-XXthroughputCompaction を使用する場合は、以下の例外に注意してください。
-XXfullCompaction、-XXcompactRatio、-XXinternalCompactRatio、または -XXexternalCompactRatio の各オプションはこのオプションとは異なる方法で圧縮率を制限するため、このオプションをこれらのオプションと共に使用することはできない。 :pausetime、-Xgcprio:deterministic または -XpauseTarget と共に使用すると、非確定的で長すぎる休止時間が発生するおそれがある。
-XXthroughputCompaction を使用する場合は、以下の例外に注意してください。
パフォーマンスを上げるために、JRockit JVM ではオブジェクトの割り当てにスレッドローカル領域 (TLA) を使用します。このオプションでスレッドローカル領域のサイズをチューニングし、パフォーマンスに影響を与えることができます。
形式 : -XXtlaSize:<param>=<size>[k|K][m|M][g|G]
<param> は、表 3-5 に示されているパラメータの 1 つです。
-XXtlaSize に上限や下限はありません。デフォルト値は 2KB です。
このオプションは注意して使用してください。スレッドローカル領域のサイズを変更すると、パフォーマンスに重大な影響を与える可能性があります。
<size> は、通常の k、M、G の各サフィックスを使用し、バイト単位で指定します。
-XXtlasize:min=2k,preferred=16k
-XXtlasize:min=8k,preferred=512k
| 注意 : | TLA サイズの旧式の設定 (-XXtlasize=256k) は引き続きサポートされていますが、非推奨です。旧式の設定を行うと、JRockit JVM では、fixed パラメータが使用されたものとしてオプションを解釈します。たとえば、-XXtlasize=256k を指定すると、これは -XXtlasize:fixed=256k として解釈されます。 |
最小サイズのデフォルト値は 2KB です。最小値が大きなオブジェクト制限を下回ってはなりません。大きなオブジェクトの制限を TLA の最小サイズよりも大きな値に明示的に設定すると (-XXlargeObjectLimit で設定)、TLA の最小サイズは大きなオブジェクトの制限に一致するように増やされます。
優先サイズのデフォルト値は、ヒープ サイズまたはナーサリ サイズと起動時に選択したガベージ コレクタによって異なります。表 3-6 にそれぞれのコンフィグレーションのデフォルト サイズを示します。
TLA の最小サイズや優先サイズを設定した場合、大きなオブジェクトの制限 (-XXlargeObjectLimit で設定) と最小ブロック サイズ (-XXminBlockSize で設定) は、必要に応じて、JRockit JVM により自動的に調整されることがあります。TLA の最小サイズと優先サイズ、大きなオブジェクトの制限、最小ブロック サイズの間で、常に次のような関係が維持されます。
-XXlargeObjectLimit <= -XXtlaSize:min <= -XXminBlockSize
-XXtlaSize:min <= -XXtlaSize:preferred
これらのオプションを複数設定する場合は、使用する値がこれらの条件を満たしていることを確認してください。デフォルトでは、大きなオブジェクトの制限は、TLA の最小サイズ、および TLA の優先サイズを 2 で割った値のうち、小さい方の値に設定されます。デフォルトの最小ブロック サイズは 2k です。
大きなオブジェクトの制限や最小ブロック サイズを JRockit JVM で必要に応じて自動的に調整する場合、メモリ管理のチューニングのため、TLA サイズのパラメータを主に設定することをお勧めします。
このオプションを指定すると、64 ビット Intel Itanium システムのトレース スケジューラ フレームワーク (TSF) が有効になります。
| 注意 : | このオプションは、JRockit JVM の以前のリリースの -Djrockit.codegen.tracesched=<true|false> argument に代わるものです。 |
トレース スケジューラ フレームワークを有効にするには、次のコマンドを入力します。
java-Xtsf=truemyApp
[INFO ] Trace scheduling is enabled.
-XXtsf= を指定しない場合、または false を設定した場合、トレース スケジューラ フレームワーク機能は無効です。
この機能は、64 ビット Intel Itanium システムでのみ使用できます。
| 警告 : | これは高度なチューニング オプションです。このオプションの機能を理解していて、不適切な使用によって弊害が生じても十分に対処可能な場合以外は、このオプションは使用しないでください。 |
このオプションは、ポインタセットの代わりにポインタ マトリックスを使用するように指示します。-Xgcprio:deterministic または -Xgcprio:pausetime を実行している場合は、デフォルトでポインタ マトリックスが使用されます。
java -XXusePointerMatrix myApp
このオプションと共に -XgcPrio:throughput を指定すると、スループット固有の圧縮ヒューリスティックの多くが変更または無効化されるため、一緒に使用することは避けてください。
このオプションを -XXcompactSetLimit を一緒に使用することはできません。
形式 : -XX:MaximumNurseryPercentage=<value> [1-95]
ナーサリ サイズの上限を 1 より小さい値または 95 より大きい値に設定すると、エラー メッセージが表示されます。
java -XX:MaximumNurseryPercentage=80 myApp
このオプションをシングルスペース (非世代別) ガベージ コレクタで使用することはできません。このオプションは、静的な世代別ガベージ コレクタまたは動的なガベージ コレクションの両方で使用できます。
このオプションを指定すると、Java 5.0 Update 8 で導入され、JRockit JVM R27.1.0 に含まれている、最新の高速な HashMap のハッシュ関数が有効になります。このハッシュ関数は、ハッシュの普及に伴いパフォーマンスが改善されていますが、HashMap に格納される要素の順序は変更されています。互換性の理由から、JRockit JVM 5.0 では、-XXaggressive を指定して起動した場合を除いて、デフォルトで古いハッシュ関数が使用されます。
| 注意 : | このフラグは、JRockit JVM 5.0 R27.1 でサポートされています。JRockit JVM 1.4.2 では使用できません。 |
形式 : -X:[+|-]useNewHashFunction
このオプションでは、Sun の実装形式を使用します。つまり、-XX と、新しいハッシュ関数の有効 (+) または無効 (-) を指定する演算子およびオプション名の間を、コロン (:) で区切る必要があります。
-XX:+UseNewHashFunction
-XX:-UseNewHashFunction
JRockit JVM 5.0 では、新しいハッシュ関数はデフォルトで無効です。
-XX:-UseNewHashFunction で新しいハッシュ関数が明示的に無効にされていない限り、XXaggressive を指定すると新しいハッシュ関数が有効になります。
このオプションでは、java.lang.Thread.setPriority() および関連する API を使用して、Java スレッドの優先順位を制御できます。この機能が無効の場合、これらの API を使用しても効果はありません。
| 警告 : | この機能は実験的な機能であり、Oracle は現時点ではこの機能をサポートしていません。この機能を間違って使用すると、深刻なパフォーマンスの問題が発生するおそれがあります。 |
形式 : -XX:[+|-]UseThreadPriorities
このオプションでは、Sun の実装形式を使用します。つまり、-XX と、java.lang.Thread.setPriority() と関連 API の有効 (+) または無効 (-) を指定する演算子およびオプション名の間を、コロン (:) で区切る必要があります。
-XX:-UseThreadPriorities。デフォルトでは、スレッドの優先順位は無効です。
このオプションを使用できるかどうかは、使用しているプラットフォームによって異なります。
このオプションは、よく割り当てられる文字列のキャッシュを有効にします。このオプションは Oracle JRockit 6 の P28.0.0 で導入されました。JRockit JVM 1.4.2 または 1.5.0 では使用できません。
このオプションでは、Sun の実装形式を使用します。つまり、-XX と、文字列キャッシュの有効 (+) または無効 (-) を指定する演算子およびオプション名の間を、コロン (:) で区切る必要があります。
  
|