|
非標準の (-X
) コマンドライン オプションは、Oracle JRockit JVM 専用のオプションです。さまざまな Java アプリケーションのニーズに合わせて JRockit JVM の動作を変更します。これらのオプションはすべて -X
で始まり、他の JVM では機能しません (反対に、他の JVM で使用される非標準のオプションは JRockit JVM では機能しません)。
注意 : | これらのオプションは非標準であるため、常に変更される可能性があります。 |
この章は、JRockit JVM で設定できるすべての -X
起動フラグに関する詳細なリファレンスです。各オプションの説明は、アルファベット順に並んでいます。
このオプションでは、起動クラス ファイルを検索するディレクトリ、JAR
アーカイブ、および ZIP
アーカイブのリストをセミコロンで区切って指定します。これらは Java 2 SDK に含まれる起動クラス ファイルの代わりに使用されます。
注意 : | このオプションを使用して rt.jar のクラスをオーバーライドするアプリケーションをデプロイしないでください。デプロイすると、Java 2 Runtime Environment バイナリ コード ライセンス違反になります。 |
形式 : -Xbootclasspath
<; (Windows) または : (Linux) で区切ったディレクトリおよび zip/jar>
起動時にこのオプションを入力し、ブートストラップ クラスおよびリソースのデフォルトのクラスパスを作成します。このオプションは、例に示すように、ラクダ記法ではなく、小文字で入力する必要があります。
ディレクトリ、JAR アーカイブ、および ZIP アーカイブのパスをセミコロンで区切って指定するという点で、このオプションは -Xbootclasspath に似ています。ただし、このリストはデフォルトのブートストラップ クラス パスの末尾に追加されます。
形式 : -Xbootclasspath/a
<; (Windows) または : (Linux) で区切ったディレクトリおよび zip/jar>
起動時にこのオプションを入力し、ディレクトリ、JAR アーカイブ、および ZIP アーカイブのリストをブートストラップ クラスおよびリソースのデフォルトのクラスパスの末尾に追加します。このオプションは、例に示すように、ラクダ記法ではなく、小文字で入力する必要があります。
ディレクトリ、JAR アーカイブ、および ZIP アーカイブのパスをセミコロンで区切って指定するという点で、このオプションは -Xbootclasspath に似ています。ただし、このリストはデフォルトのブートストラップ クラス パスの先頭に追加されます。
形式 : -Xbootclasspath/p
<; (Windows) または : (Linux) で区切ったディレクトリおよび zip/jar>
起動時にこのオプションを入力し、ディレクトリ、JAR
アーカイブ、および ZIP
アーカイブのリストをブートストラップ クラスおよびリソースのデフォルトのクラスパスの先頭に追加します。このオプションは、例に示すように、ラクダ記法ではなく、小文字で入力する必要があります。
このオプションを使用して、ガベージ コレクションされたオブジェクトが占有しているメモリがクリアされる時期を定義します。オブジェクトがクリアされる時期として、割り当て時、ガベージ コレクション時、またはスレッドローカル領域の割り当て時を設定できます。
注意 : | このオプションは、JRockit JVM R25 では非推奨です。以降のリリースでこのオプションを使用した場合、例外が送出されずに受け付けられますが、何も起こりません。 |
注意 : | -XclearType に関する以下の情報は、JRockit JVM R24 以前にのみ適用されます。 |
表 2-1 の説明に従って、必要なパラメータ (<param>
) を設定し、オブジェクトがクリアされる時期を定義します。
-XclearType
を設定しない場合、デフォルトでオブジェクトがクリアされる時期は、次のようになります。
-Xdebug
によって、Java Virtual Machine Tools Interface (JVMTI) が使用する JVM 内のデバッグ機能が有効になります。JVMTI は、デバッガやプロファイリング ツールで使用される低レベルのデバッグ インタフェースです。JVMTI を使用すると、JVM で動作しているアプリケーションの状態を調べ、実行を制御することができます。
プロファイラが頻繁に使用する JVMTI のサブセットは、いつでも有効です。しかし、コードをステップ単位に実行したり、ブレークポイントを設定したりできる、デバッガが使用する機能は、オーバーヘッドを伴うため、常に有効なわけではありません。この機能を有効にするには、-Xdebug
オプションを使用する必要があります。
警告 : | -Xdebug オプションを指定して実行する場合、JVM は通常の速度では実行されません。このため、プロダクション環境で実行されるアプリケーションに対しては、このオプションを使用しないでください。 |
java
-Xdebug
-Xrunjdwp:transport=dt_socket,server=y,suspend=n
myApp
-Xgc
は、静的なガベージ コレクタを設定するときに使用します。静的なガベージ コレクタは表 2-2 のように分類されます。
場合によっては、これらの静的なガベージ コレクタのパフォーマンスの方が、動的なガベージ コレクション モードや、-server
フラグまたは -client
フラグを指定して使用できるデフォルトのコレクタよりも、ユーザのニーズに適していることがあります。また、旧バージョンの JRockit JVM 用に記述したスクリプトがあり、その中でこれらのコレクタを実装している場合、そのスクリプトは一切修正することなく引き続き使用できます。ただし、スクリプトで世代別コピー ガベージ コレクタを使用している場合は除きます (世代別コピー ガベージ コレクタは使用できなくなりました)。
表 2-3 に示すいずれかのガベージ コレクション タイプ (<gcType>
) と共に -Xgc
を使用して、必要なガベージ コレクタ アルゴリズムを指定します。
-XXsetGC
を設定すると、-Xgc
がオーバーライドされる。逆についても同様。コマンドラインで最初に指定されていたオプションが無視される。-Xgc
を設定すると、-server
および -client
の効果の一部がオーバーライドされる。
-Xgcpause
オプションでは、実行中にガベージ コレクタによって発生した休止時間を出力します。休止時間はアプリケーションの実行中に画面に表示されます。
このオプションの効果は、-Xverbose
:gcpause
と同じです。
起動時にこのオプションを使用します。休止時間が発生すると、コード リスト 2-1 に示すように、画面にレポートが出力されます。
[memory ] old collection phase 0-2 pause time: 100.794255 ms
[memory ] nursery collection pause time: 4.121775 ms
[memory ] nursery collection pause time: 185.137069 ms
[memory ] old collection phase 4-5 pause time: 147.672697 ms
[memory ] (pause includes yc: 142.537 ms, compaction: 1.317 ms, update ref: 1.41 3 ms)
[memory ] nursery collection pause time: 7.075705 ms
[memory ] old collection phase 5 pause time: 0.300176 ms
-XgcPrio
は、動的なガベージ コレクション モードを設定します。このガベージ コレクタは、すべてのタイプのガベージ コレクション ヒューリスティックを組み合わせ、それに従ってパフォーマンスを最適化します。このガベージ コレクタを実行するときは、コレクション時の最適なメモリ スループットと最小限の休止時間のどちらがアプリケーションにとって効果的かを決めるだけで済みます。動的なガベージ コレクタは実行時に、選択したコレクタのタイプを、アプリケーションに最適なものになるように調整します。
注意 : | このコマンドライン オプションは、JRockit JDK 1.4.2_10 R26.2 以降のバージョンと、JRockit JDK 5.0 および JRockit JDK 6 のすべてのバージョンでサポートされます。 |
-XgcPrio
を表 2-4 に示すいずれかのガベージ コレクション タイプ (<gcType>
) と組み合わせます。
-XpauseTarget を使用して変更できる。
|
-Xgcprio:throughput)
に最適化されている動的ガベージ コレクション モードになる。-Xgc
:singlecon
) を使用する静的コレクタになる。
-XgcPrio を使用すると、以下のような特定のオプションに影響を与えます。
-XgcPrio
を設定すると、-server
および -client
の効果の一部がオーバーライドされる。-Xns
を設定している場合、動的なナーサリ サイズの設定がオーバーライドされる。「-Xns
」を参照してください。-XpauseTarget
を使用すると、-XgcPrio:pausetime
および XgcPrio:deterministic
の休止時間を設定できる。
動的なガベージ コレクタを、-Xgc
や -XXsetGC
で設定される静的なガベージ コレクタと組み合わせることはできません。
-XXdisableGCHeuristics
を設定した場合、-XgcPrio
オプションの結果としてガベージ コレクション方式が変更されることはありません。
-XgcReport
オプションでは、実行終了時にガベージ コレクションの統計を示すレポートを生成します。このレポートを使用して、アプリケーションにとって最も効果的なガベージ コレクタを使用しているかどうかを判断できます。
レポートでは、統計を「若いコレクション」と「古いコレクション」に分け、それぞれのタイプについて以下の情報が出力されます。
このオプションの効果は、-Xverbose
:gcreport
と同じです。
コード リスト 2-2 に示すように、-Xgcreport
は若い世代と古い世代の両方に関するコレクションの詳細なプロファイルを表示します。
[memory ] Memory usage report
[memory ]
[memory ] young collections
[memory ] number of collections = 50
[memory ] total promoted = 4628936 (size 260614072)
[memory ] max promoted = 108102 (size 6083128)
[memory ] total GC time = 4.381 s
[memory ] mean GC time = 87.623 ms
[memory ] maximum GC Pauses = 125.264 , 153.122, 244.682 ms
[memory ]
[memory ] old collections
[memory ] number of collections = 6
[memory ] total promoted = 0 (size 0)
[memory ] max promoted = 0 (size 0)
[memory ] total GC time = 0.701 s (pause 0.701 s)
[memory ] mean GC time = 116.833 ms (pause 116.830 ms)
[memory ] maximum GC Pauses = 134.081 , 190.973, 215.381 ms
[memory ]
[memory ] number of parallel mark phases = 6
[memory ] number of parallel sweep phases = 4
[memory ] number of concurrent sweep phases = 2
Mon Nov 1 16:50:34 WEST 2004
このオプションでは、Java ヒープや JVM の他の領域に、可能であればラージ ページを使用するように JRockit JVM に指示します。ラージ ページを使用すると、アプリケーションでプロセッサ内の TLB (Translation Look-aside Buffer) をより効果的に利用できるようになります。
注意 : | このオプションは -XXlargePages の機能と重複しますが、ラージ ページを有効にする場合は、このオプションが優先オプションです。 |
Windows、Linux、および Solaris は、x86、IPF、および SPARC アーキテクチャ上で複数のページ サイズをサポートしています。x86 では 4KB と 4MB (PAE モードでは 2KB と 2MB) がサポートされます。一方、IPF と SPARC では、モデルに応じて 4KB から 256MB の範囲のさまざまなサイズがサポートされます。
形式 : -XlargePages:exitOnFailure=true
デフォルトでは、-XlargePages
が有効になっているときにラージ ページを取得できない場合、JVM はラージ ページを使用せずに実行を継続します。十分に大規模なページを取得できない場合は、この拡張オプションを使用してこの動作をオーバーライドし、JVM を強制的に終了します。この拡張オプションは、JRockit JVM R27.5 以降のリリースでサポートされています。
このオプションを使用する場合は、マシンでラージ ページをコンフィグレーションする必要があります。そのためには、次のいずれかの手順に従います。
echo nn > /proc/sys/vm/nr_hugepages
この手順は、マシンの起動後にできるだけ早く行う必要があります。メモリを使用しているうちに断片化が発生し、指定したページ数を Linux が割り当てられなくなる場合があるからです。
注意 : | 管理者特権がない場合は、以下の手順の実行をシステム管理者に依頼する必要があります。 |
hugetblfs
ファイル システムを利用できるようにします。mount -t hugetlbfs nodev /mnt/hugepages
mount
コマンドを使用する方法と、chmod
および chown
コマンドを使用する方法のどちらでも実行できます。
Linux のラージ ページの詳細については、Linux カーネルのドキュメントに含まれる vm/hugetlbpage.txt
ファイルを参照してください。
アプリケーションでのラージ ページの使用を有効にするためにオペレーティング システムのコンフィグレーションを行う必要はありません。
JRockit JVM がラージ ページの取得に失敗した場合は、次のような警告が出力されますが、実行は続行されます。
[WARN ] Unable to acquire large pages for the heap, using normal pages
-XXlargePages
はデフォルトでは無効になっています。
このオプションは、JRockit JVM と管理サーバを同時に起動します。また、SSL 暗号化や認証などのセキュリティ機能を有効にしてコンフィグレーションを行ったり、明示的に無効にしたりできます。
形式 : -Xmanagement[:<argument1>
=<value1>
[,<argument2>
=<value2>
]]
argumentn
および valuen
は、表 2-5 のように定義されます。
JRockit JVM R27.1.0 にこのオプションが実装されたことが、製品の以前のバージョンとの違いです。過去のバージョンでは、このオプションによって、以下が動作している管理サーバが有効になりました。
元の RMP 実装には、セキュリティ機能はありませんでした。JRockit JVM 5.0 には、認証および SSL 暗号化という新しいセキュリティ機能が含まれています。これらは J2SE 5.0 で導入されましたが、JRockit JVM 1.4.2 では類似のセキュリティ機能は有効ではありませんでした。
最新の JRockit JVM デプロイメントのセキュリティ リスクおよびミッションクリティカルな特性により、JRockit JVM
の新しいデフォルトの動作では、セキュリティを明示的に無効にするか、またはコンフィグレーションを行い有効にするかが要求されます。これらの手順を実行しないと、管理サーバはリモート アクセス用のポートを開きません。また、セキュリティ コンフィグレーションに関するエラー メッセージが表示され、JVM 起動が停止する可能性があります。
-Xmanagement
を指定すると、ローカルなメモリ内エージェントも有効になり、開発者の視点から見た場合のユーザ操作が改善されます。たとえば、あるマシンの JRockit JVM で WLS インスタンスを実行している開発者は、-Xmanagement
を指定することによってローカルなメモリ内エージェントを有効にして、別のマシンの Oracle JRockit Mission Control Client からそのエージェントに接続できます。一方、開発者は、JRockit Mission Control からローカル アクセスするのに -Xmanagement
を指定する必要はありません。メモリ内エージェントには、いつでもローカルにアクセスできます。つまり、マシン上で複数の JRockit JVM インスタンスが実行しているときに JRockit Mission Control Client を起動すると、JVM が自動的に検出され、アクセスすることができます。JRockit JVM インスタンスと JRockit Mission Control Client が同じユーザによって実行されている場合、このような種類のローカル アクセスを許可することによってのみ、セキュリティが適用されます。これが該当するのは、モニタしている JRockit JVM が R27.1 以降の場合だけです。
セキュリティを適用しない管理エージェントを有効にするには、SSL および認証を無効にすることを指定する必要があります。また、JMX サーバ ポートを、JRockit JVM 5.0 で明示的に指定する必要があります。
ユーザビリティを最大限に高めるには、自動検出メカニズムも有効にしてください。これによって、JRockit Mission Control は、マルチキャスト ベースの JRockit Discovery Protocol を通じて、動作している JRockit JVM インスタンスを自動的に検出できます。これは、ローカル サブネットでのみ有効です。
同時に動作する RMP 接続数を制限するには、-Djrockit.managementserver.maxconnect
を設定します。
デフォルト値は、使用している JRockit JVM によって異なります。
-Xms
オプションでは、Java ヒープの初期サイズと最小サイズを設定します。Java ヒープ (「ヒープ」) は、メモリのブロックがオブジェクトに割り当てられ、ガベージ コレクション時に解放されるメモリの部分です。
注意 : | -Xms では、JVM で使用できるメモリの合計量は制限されません。 |
java ヒープの初期サイズと最小サイズを 64MB に設定します。
単位を追加しないと、指定したままの値として解釈されます。たとえば、64 は 64 バイトとして解釈されます。64MB や 64KB にはなりません。
パフォーマンスを最大にするには、-Xms
を最大ヒープ サイズと同じサイズに設定します。次に例を示します。
java -Xgcprio:throughput -Xmx:64m
-Xms:64m
myApp
このオプションを設定しない場合、Java ヒープの最小サイズは (実行中のモードに応じて) デフォルトで次のように設定されます。
Java ヒープの初期サイズを、最小サイズの 8MB より小さい値に設定することはできません。それより小さい値に設定しようとしても、JRockit JVM デフォルトの 8 MB に設定されます。
-Xms
の値は、-Xmx
(Java ヒープの最大サイズ) に設定された値を超えることはできません。
このオプションでは、Java ヒープの最大サイズを設定します。Java ヒープ (「ヒープ」) は、メモリのブロックがオブジェクトに割り当てられ、ガベージ コレクション時に解放されるメモリの部分です。実行中のオペレーティング システムの種類によって、Java ヒープに設定できる最大値は異なります。
注意 : | -Xmx では、JVM で使用できるメモリの合計量は制限されません。 |
単位を追加しないと、指定したままの値として解釈されます。たとえば、64 は 64 バイトとして解釈されます。64MB や 64KB にはなりません。
-Xmx
オプションと -Xms
オプションを組み合わせて使い、Java ヒープ サイズを制限します。Java ヒープが -Xmx
より大きいサイズになることはありません。また、-Xms
値を「最小ヒープ サイズ」として使用し、固定のヒープ サイズを設定できます。たとえばベンチマーク テストを実行する場合には、-Xms = -Xmx
のように設定します。
Linux IA32 上の JRockit JVM R26.0.0 では、オブジェクトを割り当てるためのメモリ設定の段階で問題が発生する場合があります。この問題の発生時には次のメッセージが表示されます。
[JRockit] ERROR: Fatal error in JRockit during memory setup phase.
Try to reduce the heap size using -Xmx:<size>m, i.e. “-Xmx:16m”. Could
not create the Java virtual machine.
この状況を回避するには、-Xmx
の値を変更しながら再試行を繰り返して、正常な設定が可能なヒープ サイズを特定してください。
注意 : | この問題が確認されているのは R26.0.0 の場合です。 |
このオプションを設定しない場合、Java ヒープの最大サイズは、表 2-6 に示すように、プラットフォームとシステム内のメモリの量に応じて異なります。
このオプションでは、クラスのガベージ コレクションを無効にします。-XnoClassGC
を使用すると、ガベージ コレクションの時間をある程度節約し、アプリケーション実行時の中断を短くすることができます。
起動時に -XnoClassGC
を指定すると、myApp
で指定したアプリケーションのクラス オブジェクトはガベージ コレクションの対象外となり、常に生存していると見なされます。これにより、永続的に占有されるメモリが増えるため、注意して使用しないと、メモリ不足例外が送出されます。
このオプションは、JRockit JVM がサービスとして実行されている場合に、CTRL_LOGOFF_EVENT
または SIGHUP
を受け取ることによって起こり得る障害を回避するために役立ちます。こうしたイベントを受け取ると、VM は停止処理を開始しようとしますが、オペレーティング システムが実際にはプロセスを終了させないため、停止処理は失敗します。
注意 : | -XnoHup は、Sun Microsystems が HotSpot JVM 用に開発したコマンドライン オプション -Xrs に似ています。JRockit JVM では、-Xra と -Xnohup の両方をサポートしています。-Xra を使用しても、-Xnohup を使用した場合と動作は同じです。 |
JRockit JVM をサービスとして実行している場合 (Web サーバのサーブレット エンジンなど)、起動時にこのコマンドを入力すると、JVM は CTRL_LOGOFF_EVENT
イベントまたは SIGHUP
イベントの監視も処理も行わなくなります。
-Xnohup
を指定する場合は、以下の点に注意してください。
このオプションは、適応性のある最適化を無効にします。通常、最適化されたコードは、最適化されていないコードより高速に実行されますが、コードを最適化するのに要する時間が、望ましくない処理の遅れを引き起こすことがあります。-XnoOpt
を指定すると、最適化を無効にすることによって、このような遅延を回避できます。このオプションは、システム クラッシュや起動時のパフォーマンス不足など、JVM またはアプリケーションの問題が最適化に関係しているおそれがある場合にも役立ちます。最適化を無効にして、アプリケーションを再実行してみてください。正常に動作する場合は、コードの最適化に問題があると判断できます。
-XnoOpt
を使用すると、効率的でなく、アプリケーションのパフォーマンスに深刻な影響を及ぼすおそれがあるコードをコンパイルし続けることになります。
-XnoOpt
を設定しない場合、コードは通常どおりに最適化されます。
-XXnoJITInline
を使用する場合は、-XnoOpt
も使用する必要があります。-XXnoJITInline
は、メソッドが最初にコンパイルされるときだけインライン化を無効にします。一緒に -XnoOpt
を設定しなければ、コードが最適化されるときにメソッドがインライン化される可能性があります。
-Xns
ではナーサリ サイズを設定します。JRockit JVM でナーサリが使用されるのは、世代別ガベージ コレクション モデルを使用しているときです。つまり、動的なガベージ コレクタが世代別ガベージ コレクション モデルを使用すべきと判断した場合、または静的な世代別コンカレント ガベージ コレクタ (-Xgc
:
gencon
) が選択されている場合です。また、-Xns
を使用して、動的なガベージ コレクタ (-XgcPrio) の実行中に静的なナーサリ サイズを設定することもできます。
ナーサリ サイズの値は、ヒープに設定された最大値を超えることはできません。
デフォルト値は、動的なガベージ コレクタ (デフォルトのガベージ コレクタ) を使用するか、静的なガベージ コレクタを選択するかによって異なります。表 2-7 を参照してください。
-Xns
を設定できるのは、動的なガベージ コレクタ (-XgcPrio
) または静的な世代別ガベージ コレクタ (-Xgc:gencon
または -Xgc:genpar
) を使用している場合のみ。-XXlargeObjectLimit
のサイズの少なくとも 4 倍で、かつ、-Xmx
を超えてはならない。
このオプションでは、短い休止時間を最適化する動的なガベージ コレクション モード (-XgcPrio
:
pausetime
) と確定的な休止時間を最適化する動的なガベージ コレクション モード (-XgcPrio
:
deterministic
) の目標休止時間を設定します。目標値が休止時間の目標として使用されます。目標を設定することで、動的なガベージ コレクタは自身をより正確にコンフィグレーションし、休止時間を目標値に近づけることができます。このオプションを使用すると、1 ミリ秒から 5 秒の間で目標休止時間を指定できます。確定的ガベージ コレクタが使用する場合は、値を 200 ミリ秒未満に設定できる。ただし、-XgcPrio
:
deterministic
の有効なライセンスが必要である。
形式 : -XpauseTarget=
<target value>
-XpauseTarget=<target value>
-Xgcprio:pausetime
このオプションで設定する目標は、柔軟な目標と見なされることに注意してください。つまり、目標を 100 ミリ秒に指定した場合、ガベージ コレクタは休止時間が 100 ミリ秒にできるだけ近づくようなコンフィグレーションを目指して自身をチューニングします。しかし、ガベージ コレクタをどれほど (静的または動的に) チューニングしても、この目標を実現できないアプリケーションとヒープ コンフィグレーションを使用している場合は、目標が守られません。このオプションは目標休止時間を指定するだけで、最大許容休止時間を指定するわけではありません。
注意して使用すれば、このオプションによって休止時間が改善されます。しかし注意せずに使用すると、ガベージ コレクタの動作に異常が起きることがあります。
-XgcPrio
:
pausetime
で -XpauseTarget
を使用する場合、デフォルトの目標の設定は 500 ミリ秒です。-XgcPrio
:
deterministic
を使用している場合、デフォルト値は 30 ミリ秒です。
通常、このオプションは動的な、休止時間を最適化するガベージ コレクション モード (-XgcPrio
:
pausetime
または -XgcPrio
:
deterministic
)
で使用する必要があります。ガベージ コレクタを指定しない場合は、このオプションによってデフォルトのガベージ コレクタが変更され、休止時間を最適化するガベージ コレクタ (-XgcPrio
:
pausetime
を指定したときと同じコレクタ) が使用されます。
Oracle JRockit Real Time が使用する場合は、-XgcPauseTarget
を 200 ミリ秒未満に設定してガベージ コレクタを指定しません。ガベージ コレクタを -XgcPrio
:
deterministic
に設定します。
-XpauseTarget
を使用する場合は、以下の例外に注意してください。
注意 : | -Xrs は、Sun Microsystems が HotSpot JVM 用に開発した非標準オプションです。JRockit JVM では、このオプションが引き続きサポートされます。ただし、JRockit JVM の非標準オプション -Xnohup で同じ機能が提供されています。 |
-Xrs
は、JVM によるオペレーティング システム シグナルの使用を減らします。JVM をサービスとして実行している場合 (Web サーバのサーブレット エンジンなど)、JVM は CTRL_LOGOFF_EVENT
を受け取ることがありますが、停止処理を開始すべきではありません。オペレーティング システムが実際にはプロセスを終了させないからです。このような障害を回避するために、-Xrs
コマンドライン オプションを使用すると、コンソール制御ハンドラがインストールされなくなります。この場合、JVM は CTRL_C_EVENT
、CTRL_CLOSE_EVENT
、CTRL_LOGOFF_EVENT
、または CTRL_SHUTDOWN_EVENT
の監視および処理を行いません。
JRockit JVM をサービスとして実行している場合 (Web サーバのサーブレット エンジンなど)、起動時にこのコマンドを入力すると、JVM は CTRL_LOGOFF_EVENT
イベントまたは SIGHUP
イベントの監視も処理も行わなくなります。
-Xnohup
を指定する場合は、以下の点に注意してください。
このオプションでは、JDWP の JPDA リファレンス実装をロードします。このライブラリはターゲット VM に配置され、JVMDI と JNI を使用してターゲット VM とやり取りします。独立したデバッガ アプリケーションとの通信には、トランスポートと JDWP プロトコルを使用します。
形式 : -Xrunjdwp:<name1>[=<value1>],<name2>[=<value2>]...
-Xrunjdwp
オプションは、さらに表 2-8 に示すいずれかのサブオプションを指定して修飾することができます。
java-Xrunjdwp:transport=dt_socket,server=y,address=8000
myApp
-Xss
では、スレッド スタック サイズを設定します。スレッド スタックは、各 Java スレッドが内部的に使用するために割り当てられるメモリ領域です。ここにスレッドのローカルの実行状態が格納されます。
単位を追加しないと、指定したままの値として解釈されます。たとえば、64 は 64 バイトとして解釈されます。64MB や 64KB にはなりません。
-Xss
のデフォルト値は、表 2-9 に示すようにプラットフォームごとに異なります。
このオプションは、厳密な浮動小数点演算をすべてのクラスのすべてのメソッドでグローバルに有効にします。-XstrictFP
を設定すると、JVM は Java 仕様で要求されているより高い精度で、より広い値の範囲を使って計算を行います。-XstrictFP
を使用した場合、コンパイラは Java 仕様に厳密に準拠するコードを生成し、どのプラットフォームでもまったく同じ結果が得られるようにします。-XstrictFP
を設定しないと、JVM は浮動小数点値をそれほど厳密に適用しません。
このオプションは、Java キーワード strictfp
に似ています。ただし、このキーワードはクラス レベルで適用されるのに対し、-XstrictFP
はグローバルに適用されます。strictfp
の詳細については、「Java Language Specification」を参照してください。
-Xverbose
を使用すると、JRockit JVM はシステムに関する具体的で細かい情報を出力します。デフォルトでは、エラー メッセージ用の標準出力 (stderr
) に出力されますが、-XverboseLog コマンドライン オプションを使用してファイルにリダイレクトすることもできます。表示される情報は、オプションと一緒に指定するパラメータによって異なります。たとえば、パラメータ cpuinfo
を指定すると、CPU に関する情報が表示され、ハイパー スレッディングが有効かどうかを JVM が判断できるかどうかがわかります。表 2-10 は、-Xverbose
オプションに使用できるパラメータを示しています。
形式 : -Xverbose:<param[=level]>
param
は表 2-10 に示されているパラメータの 1 つであり、level
は「ログ レベル」で説明されているログ レベルです。
java
-Xverbose:gcpause=debug
myClass
実行時の休止時間のサンプリングと情報の表示が有効になり、JRockit JVM の動作の詳細な情報と共にメッセージが記録されます。
注意 : | 複数のパラメータを使用するには、次のようにカンマで区切ります。 |
注意 : | -Xverbose:gc,opt |
[INFO ][class ] Initializing bootstrap classes...
|
|||
[codegen] 0 : 17.9411 ms
|
|||
[excepti][00002] java/lang/NumberFormatException: null
|
|||
[INFO ][load ] opened zip
|
|||
[memory ] 12.875: nursery GC 89648K->89716K (89716K), 3.296 ms
|
|||
memdbg 出力も表示する。アプリケーションのスループットを重視するように最適化された動的なガベージ コレクタ (-XgcPrio : throughput ) を実行する JVM で、memdbg を指定した場合、レポートは次のようになる。
[memdbg ] nursery GC 3: promoted 22788 objects (1246K) in 28.472 ms
|
|||
|
|||
[memory ] GC strategy: gencon
|
|||
[memory ] GC strategy: singlecon
|
|||
[memory ] GC strategy: parallel
|
|||
memory または gc を指定した場合、レポートは次のようになる。
[memory ] GC strategy: System optimized over throughput (initial strategy singleparpar)
|
|||
-Xverbose:referents は、R27.2 より前の JRockit JVM バージョンの -Djrockit.verboserefs オプションに相当する。
|
|||
System.currentTimeMillis() および System.nanoTime() の値。これらを使用すると、異なるプロセス間のログ出力を相関させることができる。starttime の冗長出力は次のようになる。
[startti] VM start time: 1152871839957 millis 171588375730523 nanos |
|||
-Xverbose:memdbg の出力で System.gc() の呼び出しによって開始されたガベージ コレクションまたは「other 」としてマークされているために開始されたガベージ コレクションに対する通知を行う。たとえば、ガベージ コレクションを暗黙的に開始する JMAPI 関数や診断コマンド runsystemgc の呼び出しなど。
|
|||
ログ レベルは、ログに記録される情報のレベルを指定します。JRockit JVM では、表 2-11 に示されている 6 種類のログ レベルを使用します。
-Xverbose
を設定しないと、以下のオプションは機能しません。
JRockit JVM が冗長な出力に追加する「デコレーション」を設定するには、このオプションを使用します。デコレーションは、冗長な出力にさらに意味を持たせるために使用される、通常はシステム関連の追加情報です。メッセージの生成元のモジュールの名前や、現在の JRockit JVM セッションが開始してからの経過時間 (ミリ秒単位) などがその例です。
形式 : -Xverbosedecorations=
<decoration names>
java -Xverbose:gcpause-XverboseDecorations=timestamp
,modulemyApp
注意 : | control-break ハンドラ verbosity と引数 decorations を一緒に使用することもできます。 |
指定できるデコレーションを表 2-12 に示します。
-XverboseTimeStamp オプションを使用した場合に表示される値と同じ値。
|
デコレーションを指定せずに -XverboseDecorations
を使用すると、冗長出力では、module、timestamp、および pid がこの順序で表示されます。以下に例を示します。
D:\jrockits\R27.1.0_R27.1.0-23_1.4.2\bin>java -Xverbose:load -Xverbosedecorations -cp L:\src\ HelloWorld
[load ][Wed Sep 13 19:43:14 2006][00728] opened zip D:\jrockits\R27.1.0_R27.1.0-23_1.4.2\jre\lib\rt.jar
このオプションは、冗長ロギングを有効にする -Xverbose
オプションも設定されている場合にのみ使用できます。
このオプションでは、Oracle JRockit JVM からのメッセージ (冗長出力やエラー メッセージなど) を stderr
ではなく、指定したファイルに出力します。
形式 : -Xverboselog:myFile.txt
ファイル名と拡張子を指定してこのコマンドを使用すると (myFile.txt
など)、JVM は指定したファイルにロギング情報を書き込みます。
java -Xverbose:gcpause-Xverboselog:verboseText.txt
myApp
このコマンドでは、クラス myApp
の冗長なロギング情報が verboseText.txt
という名前のファイルに書き込まれます。
このオプションは、冗長ロギングを有効にする -Xverbose オプションが設定されている場合にのみ機能します。
このオプションは、冗長出力にタイムスタンプを追加します。イベントのログを記録するときに役立ちます。
-XverboseTimeStamp
コマンドと組み合わせると、-Xverbose
で生成される他の情報と共にタイムスタンプを出力できます。
java -Xverbose-XverboseTimeStamp
myApp
次のように、-XverboseTimeStamp
で生成される出力は、-Xverbose
で出力される情報よりも前に表示されます。
L:\src>D:\jrockits\R27.1.0_R27.1.0-13_1.4.2\bin\java -Xverbose
-XverboseTimeStamp HelloWorld[load ][Mon Sep 25 09:57:56 2006][00624] opened zip
D:\jrockits\R27.1.0_R27.1.0-13_1.4.2\jre\lib\rt.jar
このオプションは、冗長出力が -Xverbose
を使用して有効になっている場合、または実行時に有効になっている場合にのみ適用されます。
このオプションを使用すると、バイトコードの正確性を手動で検証することができます。これらのチェックを実行時に繰り返し行わずに、クラスのロード時に一度だけ行うことにより、実行時の効率を高めることができます。
このオプションを表 2-13 に示すいずれかのパラメータと組み合わせます。
このオプションを使用しない場合、デフォルトではネットワーク経由でロードされるクラスのみが検証されます (-Xverify:remote
)。