コマンドライン リファレンス

     前  次    目次     
コンテンツの開始位置

-X コマンドライン オプション

非標準の (-X) コマンドライン オプションは、Oracle JRockit JVM 専用のオプションです。さまざまな Java アプリケーションのニーズに合わせて JRockit JVM の動作を変更します。これらのオプションはすべて -X で始まり、他の JVM では機能しません (反対に、他の JVM で使用される非標準のオプションは JRockit JVM では機能しません)。

注意 : これらのオプションは非標準であるため、常に変更される可能性があります。

この章は、JRockit JVM で設定できるすべての -X 起動フラグに関する詳細なリファレンスです。各オプションの説明は、アルファベット順に並んでいます。

 

-Xbootclasspath

このオプションでは、起動クラス ファイルを検索するディレクトリ、JAR アーカイブ、および ZIP アーカイブのリストをセミコロンで区切って指定します。これらは Java 2 SDK に含まれる起動クラス ファイルの代わりに使用されます。

注意 : このオプションを使用して rt.jar のクラスをオーバーライドするアプリケーションをデプロイしないでください。デプロイすると、Java 2 Runtime Environment バイナリ コード ライセンス違反になります。

使用法

形式 : -Xbootclasspath <; (Windows) または : (Linux) で区切ったディレクトリおよび zip/jar>

起動時にこのオプションを入力し、ブートストラップ クラスおよびリソースのデフォルトのクラスパスを作成します。このオプションは、例に示すように、ラクダ記法ではなく、小文字で入力する必要があります。

影響を受けるフラグや他のオプション

例外

なし

 

-Xbootclasspath/a

ディレクトリ、JAR アーカイブ、および ZIP アーカイブのパスをセミコロンで区切って指定するという点で、このオプションは -Xbootclasspath に似ています。ただし、このリストはデフォルトのブートストラップ クラス パスの末尾に追加されます。

使用法

形式 : -Xbootclasspath/a <; (Windows) または : (Linux) で区切ったディレクトリおよび zip/jar>

起動時にこのオプションを入力し、ディレクトリ、JAR アーカイブ、および ZIP アーカイブのリストをブートストラップ クラスおよびリソースのデフォルトのクラスパスの末尾に追加します。このオプションは、例に示すように、ラクダ記法ではなく、小文字で入力する必要があります。

影響を受けるフラグや他のオプション

例外

なし

 

-Xbootclasspath/p

ディレクトリ、JAR アーカイブ、および ZIP アーカイブのパスをセミコロンで区切って指定するという点で、このオプションは -Xbootclasspath に似ています。ただし、このリストはデフォルトのブートストラップ クラス パスの先頭に追加されます。

使用法

形式 : -Xbootclasspath/p <; (Windows) または : (Linux) で区切ったディレクトリおよび zip/jar>

起動時にこのオプションを入力し、ディレクトリ、JAR アーカイブ、および ZIP アーカイブのリストをブートストラップ クラスおよびリソースのデフォルトのクラスパスの先頭に追加します。このオプションは、例に示すように、ラクダ記法ではなく、小文字で入力する必要があります。

影響を受けるフラグや他のオプション

例外

なし

 

-Xcheck:jni

JNI 関数に対する追加のチェックを有効にします。

使用法

形式 : -Xcheck:jni

起動時にこのオプションを指定します。

影響を受けるフラグや他のオプション

なし

例外

なし

 

-XclearType

非推奨

このオプションを使用して、ガベージ コレクションされたオブジェクトが占有しているメモリがクリアされる時期を定義します。オブジェクトがクリアされる時期として、割り当て時、ガベージ コレクション時、またはスレッドローカル領域の割り当て時を設定できます。

注意 : このオプションは、JRockit JVM R25 では非推奨です。以降のリリースでこのオプションを使用した場合、例外が送出されずに受け付けられますが、何も起こりません。
注意 : -XclearType に関する以下の情報は、JRockit JVM R24 以前にのみ適用されます。

使用法

形式 : -XclearType:<param>

表 2-1 の説明に従って、必要なパラメータ (<param>) を設定し、オブジェクトがクリアされる時期を定義します。

表 2-1 -XclearType で有効なパラメータ
<param>
説明
alloc
割り当て時にオブジェクトのクリアを開始する。
gc
ガベージ コレクションの実行時にオブジェクトのクリアを開始する。
local
スレッドローカル領域の割り当て時にオブジェクトのクリアを開始する。

デフォルト値

-XclearType を設定しない場合、デフォルトでオブジェクトがクリアされる時期は、次のようになります。

影響を受けるフラグや他のオプション

なし

例外

なし

 

-Xdebug

-Xdebug によって、Java Virtual Machine Tools Interface (JVMTI) が使用する JVM 内のデバッグ機能が有効になります。JVMTI は、デバッガやプロファイリング ツールで使用される低レベルのデバッグ インタフェースです。JVMTI を使用すると、JVM で動作しているアプリケーションの状態を調べ、実行を制御することができます。

プロファイラが頻繁に使用する JVMTI のサブセットは、いつでも有効です。しかし、コードをステップ単位に実行したり、ブレークポイントを設定したりできる、デバッガが使用する機能は、オーバーヘッドを伴うため、常に有効なわけではありません。この機能を有効にするには、-Xdebug オプションを使用する必要があります。

警告 : -Xdebug オプションを指定して実行する場合、JVM は通常の速度では実行されません。このため、プロダクション環境で実行されるアプリケーションに対しては、このオプションを使用しないでください。

使用法

形式 : -Xdebug

起動時にこのオプションを指定します。

次に例を示します。

java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n myApp

影響を受けるフラグや他のオプション

なし

例外

なし

 

-Xgc

-Xgc は、静的なガベージ コレクタを設定するときに使用します。静的なガベージ コレクタは表 2-2 のように分類されます。

表 2-2 静的なガベージ コレクタ
 
シングルスペース
世代別
コンカレント
シングルスペース コンカレント
-Xgc:singlecon
世代別コンカレント
-Xgc:gencon
パラレル
シングルスペース パラレル
-Xgc:singlepar (R27.2 以降) または -Xgc: parallel
世代別パラレル
-Xgc:genpar (R27.2 以降)

表 2-2

場合によっては、これらの静的なガベージ コレクタのパフォーマンスの方が、動的なガベージ コレクション モードや、-server フラグまたは -client フラグを指定して使用できるデフォルトのコレクタよりも、ユーザのニーズに適していることがあります。また、旧バージョンの JRockit JVM 用に記述したスクリプトがあり、その中でこれらのコレクタを実装している場合、そのスクリプトは一切修正することなく引き続き使用できます。ただし、スクリプトで世代別コピー ガベージ コレクタを使用している場合は除きます (世代別コピー ガベージ コレクタは使用できなくなりました)。

使用法

形式 : -Xgc:<gcType>

表 2-3 に示すいずれかのガベージ コレクション タイプ (<gcType>) と共に -Xgc を使用して、必要なガベージ コレクタ アルゴリズムを指定します。

表 2-3 -Xgc で有効なガベージ コレクション タイプ
<gcType>
説明
singlecon
シングルスペース (非世代別) コンカレント ガベージ コレクタを設定する。これはほとんどコンカレントなガベージ コレクタである。つまり、ほとんどのガベージ コレクション処理を Java アプリケーションと同時に行う。すべてのオブジェクトはシングル スペース (「世代」) に保持される。singlecon ガベージ コレクションでは、休止時間が最小限になる代わりに、アプリケーションのスループットが低下する。
gencon
世代別コンカレント ガベージ コレクタを設定する。このタイプのガベージ コレクタでは、オブジェクトが若い「世代」(ナーサリ) に割り当てられる。ナーサリが一杯になると、JRockit JVM はすべての Java スレッドを停止して、生存しているオブジェクトを若い世代から「古い世代」に移動する。これはほとんどコンカレントなガベージ コレクタである。つまり、ほとんどのガベージ コレクション処理を Java アプリケーションと同時に行う。小さくて生存期間の短い多数のオブジェクトを割り当てる多くのアプリケーションでは、singlecon ガベージ コレクタよりも gencon ガベージ コレクタの方が適している。gencon ガベージ コレクションでは、休止時間が最小限になる代わりに、ヒープ サイズが大きくなり、アプリケーションのスループットが低下する。
singlepar
parallel
シングルスペース パラレル ガベージ コレクタを設定する。パラレル ガベージ コレクタでは、ヒープが一杯になったときにすべての Java スレッドを停止し、すべての CPU を使用して、ヒープ全体の完全なガベージ コレクションを行う。パラレル コレクタはコンカレント コレクタよりも休止時間が長くなるが、スループットは最大になる。このようにパフォーマンスが最大になるため、アプリケーションで長い休止時間を許容できる場合は、シングル CPU マシン上でもパラレル ガベージ コレクタが推奨される。
singlepar に相当するガベージ コレクタは R27.2 以降のリリースで使用できる。
genpar
世代別ガベージ コレクタを設定する。このタイプのガベージ コレクタでは、オブジェクトは最初に若い世代に割り当てられる。ナーサリが一杯になると、JRockit JVM はすべての Java スレッドを停止して、パラレル ナーサリ コレクションを実行する。つまり、使用可能なすべての CPU リソースを利用して、生存しているすべてのオブジェクトを若い世代から古い世代に移動する。ヒープが一杯になると古い世代のコレクタがすべての Java スレッドを停止し、完全なパラレル ガベージ コレクションが実行される。このコレクタでは休止時間よりもスループットが優先される。
一般に、生存期間の短いオブジェクトを多数割り当てるアプリケーションでは、このコレクタの方が singlepar ガベージ コレクタよりも適している。singlepar コレクタよりもガベージ コレクションの実行回数が多くなるが、genpar コレクタの個々の休止時間の方が短く、古い世代の領域で生じる断片化は少なくなる。
このオプションは、R27.2 以降のリリースで使用できる。

デフォルト値

-Xgc には次のようなデフォルトが適用されます。

影響を受けるフラグや他のオプション

-Xgc を指定すると、以下のオプションが影響を受けます。

例外

-Xgc を使用する場合は、以下の例外に注意してください。

 

-XgcPause

-Xgcpause オプションでは、実行中にガベージ コレクタによって発生した休止時間を出力します。休止時間はアプリケーションの実行中に画面に表示されます。

このオプションの効果は、-Xverbose:gcpause と同じです。

使用法

形式 : -XgcPause

起動時にこのオプションを使用します。休止時間が発生すると、コード リスト 2-1 に示すように、画面にレポートが出力されます。

コード リスト 2-1 静的なガベージ コレクタ -Xgc:gencon と共に使用した -Xgcpause の出力 
[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

-XgcPrio は、動的なガベージ コレクション モードを設定します。このガベージ コレクタは、すべてのタイプのガベージ コレクション ヒューリスティックを組み合わせ、それに従ってパフォーマンスを最適化します。このガベージ コレクタを実行するときは、コレクション時の最適なメモリ スループットと最小限の休止時間のどちらがアプリケーションにとって効果的かを決めるだけで済みます。動的なガベージ コレクタは実行時に、選択したコレクタのタイプを、アプリケーションに最適なものになるように調整します。

注意 : このコマンドライン オプションは、JRockit JDK 1.4.2_10 R26.2 以降のバージョンと、JRockit JDK 5.0 および JRockit JDK 6 のすべてのバージョンでサポートされます。

使用法

形式 : -XgcPrio:<gcType>

-XgcPrio を表 2-4 に示すいずれかのガベージ コレクション タイプ (<gcType>) と組み合わせます。

表 2-4 -XgcPrio で有効なガベージ コレクション タイプ
<gcType>
説明
throughput
ガベージ コレクタはアプリケーションのスループットを重視する方向で最適化される。この場合、ガベージ コレクタは最大限に効率的に動作し、できるだけ多くの CPU リソースを Java スレッドに回す。ただし、ガベージ コレクタがガベージ コレクションのためにすべての Java スレッドを停止させた場合、休止時間は不定です。スループットを重視するのは、不定の休止時間がアプリケーションの動作に悪影響を及ぼさない場合にしてください。
pausetime
ガベージ コレクタはアプリケーションの短い休止時間を重視する方向で最適化される。つまり、ガベージ コレクションは、Java スレッドが休止しないように、必要に応じて Java アプリケーションと同時に機能する。コンカレント ガベージ コレクタは、最適なスループットを得るために使用されるパラレル ガベージ コレクタよりも多くのシステム リソース (CPU 時間やメモリ) を必要とするため、アプリケーションのパフォーマンスがわずかに低下する。デフォルトの目標休止時間は 200 ミリ秒。デフォルトの目標休止時間を変更する方法については、「-XpauseTarget」を参照。
deterministic
休止時間を極力短くし、所定の枠内に制限するようにガベージ コレクタが最適化される。ガベージ コレクタは、ガベージ コレクションの休止時間を、指定された休止時間の目標よりも短く維持しようとする。これが成功するかどうかは、アプリケーションとハードウェアによって決まる。たとえば、次のハードウェアで実行した場合、コレクション時に 1 GB のヒープと平均 30% 未満の実データを使用するアプリケーションでは、30 ミリ秒という目標休止時間が確認されている。
2 x Intel Xeon 3.6GHz、2MB レベル 2 キャッシュ、4GB RAM
4 x Intel Xeon 2.0GHz、0.5MB レベル 2 キャッシュ、8GB RAM
より低速のハードウェアで、ヒープ サイズや実データの大きいアプリケーションを実行すると、確定的なコレクション動作を維持できなかったり、時間の経過と共にパフォーマンスが低下したりする。逆に、高速なハードウェアで小さな実データを使用するアプリケーションを実行した場合は、目標休止時間をより小さな値に設定できる。
deterministic モードの目標休止時間のデフォルト値は 30 ミリ秒。この値は、コマンドライン オプション -XpauseTarget を使用して変更できる。

デフォルト

影響を受けるフラグや他のオプション

-XgcPrio を使用すると、以下のような特定のオプションに影響を与えます。

例外

動的なガベージ コレクタを、-Xgc や -XXsetGC で設定される静的なガベージ コレクタと組み合わせることはできません。

-XXdisableGCHeuristics を設定した場合、-XgcPrio オプションの結果としてガベージ コレクション方式が変更されることはありません。

 

-XgcReport

-XgcReport オプションでは、実行終了時にガベージ コレクションの統計を示すレポートを生成します。このレポートを使用して、アプリケーションにとって最も効果的なガベージ コレクタを使用しているかどうかを判断できます。

レポートでは、統計を「若いコレクション」と「古いコレクション」に分け、それぞれのタイプについて以下の情報が出力されます。

このオプションの効果は、-Xverbose:gcreport と同じです。

使用法

形式 : -XgcReport

コード リスト 2-2 に示すように、-Xgcreport は若い世代と古い世代の両方に関するコレクションの詳細なプロファイルを表示します。

コード リスト 2-2 動的な Xgcprio:pausetime + 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

影響を受けるフラグや他のオプション

なし

例外

なし

 

-XlargePages

このオプションでは、Java ヒープや JVM の他の領域に、可能であればラージ ページを使用するように JRockit JVM に指示します。ラージ ページを使用すると、アプリケーションでプロセッサ内の TLB (Translation Look-aside Buffer) をより効果的に利用できるようになります。

注意 : このオプションは -XXlargePages の機能と重複しますが、ラージ ページを有効にする場合は、このオプションが優先オプションです。

使用法

形式 : -XlargePages

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 以降のリリースでサポートされています。

ラージ ページをコンフィグレーションする方法

このオプションを使用する場合は、マシンでラージ ページをコンフィグレーションする必要があります。そのためには、次のいずれかの手順に従います。

Linux の場合
  1. 次のコマンドを実行し、ラージ ページに使用するメモリを予約します。
    2. echo nn > /proc/sys/vm/nr_hugepages

    nn は必要なページの数です。

    この手順は、マシンの起動後にできるだけ早く行う必要があります。メモリを使用しているうちに断片化が発生し、指定したページ数を Linux が割り当てられなくなる場合があるからです。

    注意 : 管理者特権がない場合は、以下の手順の実行をシステム管理者に依頼する必要があります。
  2. JRockit JVM でラージ ページを割り当てるには、次のコマンドを使用して、hugetblfs ファイル システムを利用できるようにします。
    3. mount -t hugetlbfs nodev /mnt/hugepages
  3. Java アプリケーションを実行するユーザに、ファイル システムに対する読み取りと書き込みの特権を与えます。この特権の付与は、mount コマンドを使用する方法と、chmod および chown コマンドを使用する方法のどちらでも実行できます。

Linux のラージ ページの詳細については、Linux カーネルのドキュメントに含まれる vm/hugetlbpage.txt ファイルを参照してください。

Windows の場合
  1. Administrator として、[スタート] メニューを開いて以下のコマンドを選択し、アプリケーションを実行するユーザにメモリ内のページをロックする特権を与えます。

    2. [コントロール パネル｜管理ツール｜ローカル セキュリティ ポリシー｜ローカル ポリシー｜ユーザ権利の割り当て｜メモリ内のページのロック]

  2. [メモリ内のページのロック] を選択します。
  3. コンピュータからログオフするか、コンピュータを再起動し、連続する十分な空きメモリを利用できるようにします。
Solaris の場合

アプリケーションでのラージ ページの使用を有効にするためにオペレーティング システムのコンフィグレーションを行う必要はありません。

ラージ ページの取得失敗

JRockit JVM がラージ ページの取得に失敗した場合は、次のような警告が出力されますが、実行は続行されます。 

[WARN ] Unable to acquire large pages for the heap, using normal pages

デフォルト値

-XXlargePages はデフォルトでは無効になっています。

影響を受けるフラグや他のオプション

なし

例外

なし

 

-Xmanagement

このオプションは、JRockit JVM と管理サーバを同時に起動します。また、SSL 暗号化や認証などのセキュリティ機能を有効にしてコンフィグレーションを行ったり、明示的に無効にしたりできます。

使用法 

形式 : -Xmanagement[:<argument1>=<value1>[,<argument2>=<value2>]]

argumentn および valuen は、表 2-5 のように定義されます。

表 2-5 -Xmanagement 引数
引数
説明
autodiscovery=<true|false>
自動検出を有効または無効にする。自動検出を有効にすると、Oracle JRockit Mission Control は、マルチキャスト ベースの JRockit Discovery Protocol を通じて、動作している JRockit JVM インスタンスを自動的に検出できる。
JRockit JVM5.0 によって有効です。
ssl=<true|false>
SSL 暗号化を有効または無効にする。
JRockit JVM5.0 によって有効です。
authenticate=<true|false>
認証を有効または無効にする。
JRockit JVM5.0 によって有効です。
port=<portNumber>
管理サーバがリモート アクセス用に開くポートを指定する。
JRockit JVM5.0 によって有効です。
class=
このオプションを指定するとクラスがロードされ、JVM 起動時の早い段階でそのクラスの空のコンストラクタが呼び出される。このコンストラクタから、新しいスレッドが起動され、そのスレッドで管理クライアントが実行される。-Xmanagement の class 引数の後には、これ以上引数を指定できない。

次に例を示します。

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 によって異なります。

R26.4 以前

J2SE 5.0 :

J2SE 1.4.2 :

5.0 R27.1

影響を受けるフラグや他のオプション

なし

例外

なし

 

-Xms

-Xms オプションでは、Java ヒープの初期サイズと最小サイズを設定します。Java ヒープ (「ヒープ」) は、メモリのブロックがオブジェクトに割り当てられ、ガベージ コレクション時に解放されるメモリの部分です。

注意 : -Xms では、JVM で使用できるメモリの合計量は制限されません。

使用法

形式 : -Xms<size>[g|G|m|M|k|K]

-Xms をメモリ値と組み合わせ、単位を追加します。

次に例を示します。

java -Xms:64m myApp

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 ヒープの最大サイズ) に設定された値を超えることはできません。

 

-Xmx

このオプションでは、Java ヒープの最大サイズを設定します。Java ヒープ (「ヒープ」) は、メモリのブロックがオブジェクトに割り当てられ、ガベージ コレクション時に解放されるメモリの部分です。実行中のオペレーティング システムの種類によって、Java ヒープに設定できる最大値は異なります。

注意 : -Xmx では、JVM で使用できるメモリの合計量は制限されません。

使用法

形式 : -Xmx<size>[g|G|m|M|k|K]

-Xmx をメモリ値と組み合わせます。

次に例を示します。

java -Xmx:1g myApp

java ヒープの最大サイズを 1GB に設定します。

単位を追加しないと、指定したままの値として解釈されます。たとえば、64 は 64 バイトとして解釈されます。64MB や 64KB にはなりません。

-Xmx オプションと -Xms オプションを組み合わせて使い、Java ヒープ サイズを制限します。Java ヒープが -Xmx より大きいサイズになることはありません。また、-Xms 値を「最小ヒープ サイズ」として使用し、固定のヒープ サイズを設定できます。たとえばベンチマーク テストを実行する場合には、-Xms = -Xmx のように設定します。

Linux で確認されている問題

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.

この場合、JRockit JVM は終了します。

この状況を回避するには、-Xmx の値を変更しながら再試行を繰り返して、正常な設定が可能なヒープ サイズを特定してください。

注意 : この問題が確認されているのは R26.0.0 の場合です。

デフォルト値

このオプションを設定しない場合、Java ヒープの最大サイズは、表 2-6 に示すように、プラットフォームとシステム内のメモリの量に応じて異なります。

表 2-6 デフォルトの最大ヒープ サイズ
リリース
プラットフォーム
デフォルトの最大ヒープ サイズ
R27.2 以前
Windows
合計物理メモリの 75%、最大 1 GB
R27.2 以前
Linux、Solaris
使用可能な物理メモリの 50%、最大 1 GB
R27.3 以降
64 ビット プラットフォームでの Windows
合計物理メモリの 75%、最大 2 GB
R27.3 以降
64 ビット プラットフォームでの Linux または Solaris
使用可能な物理メモリの 50%、最大 2 GB
R27.3 以降
32 ビット プラットフォームでの Windows
合計物理メモリの 75%、最大 1 GB
R27.3 以降
32 ビット プラットフォームでの Linux
使用可能な物理メモリの 50%、最大 1 GB

影響を受けるフラグや他のオプション

なし

例外

-Xmx を使用する場合は、以下の例外に注意してください。

 

-XnoClassGC

このオプションでは、クラスのガベージ コレクションを無効にします。-XnoClassGC を使用すると、ガベージ コレクションの時間をある程度節約し、アプリケーション実行時の中断を短くすることができます。

使用法

形式 : -XnoClassGC

起動時に -XnoClassGC を指定すると、myApp で指定したアプリケーションのクラス オブジェクトはガベージ コレクションの対象外となり、常に生存していると見なされます。これにより、永続的に占有されるメモリが増えるため、注意して使用しないと、メモリ不足例外が送出されます。

影響を受けるフラグや他のオプション

なし

例外

なし

 

-Xnohup

このオプションは、JRockit JVM がサービスとして実行されている場合に、CTRL_LOGOFF_EVENT または SIGHUP を受け取ることによって起こり得る障害を回避するために役立ちます。こうしたイベントを受け取ると、VM は停止処理を開始しようとしますが、オペレーティング システムが実際にはプロセスを終了させないため、停止処理は失敗します。

注意 : -XnoHup は、Sun Microsystems が HotSpot JVM 用に開発したコマンドライン オプション -Xrs に似ています。JRockit JVM では、-Xra と -Xnohup の両方をサポートしています。-Xra を使用しても、-Xnohup を使用した場合と動作は同じです。

使用法

形式 : -Xnohup

JRockit JVM をサービスとして実行している場合 (Web サーバのサーブレット エンジンなど)、起動時にこのコマンドを入力すると、JVM は CTRL_LOGOFF_EVENT イベントまたは SIGHUP イベントの監視も処理も行わなくなります。

影響を受けるフラグや他のオプション

なし

例外

-Xnohup を指定する場合は、以下の点に注意してください。

 

-XnoOpt

このオプションは、適応性のある最適化を無効にします。通常、最適化されたコードは、最適化されていないコードより高速に実行されますが、コードを最適化するのに要する時間が、望ましくない処理の遅れを引き起こすことがあります。-XnoOpt を指定すると、最適化を無効にすることによって、このような遅延を回避できます。このオプションは、システム クラッシュや起動時のパフォーマンス不足など、JVM またはアプリケーションの問題が最適化に関係しているおそれがある場合にも役立ちます。最適化を無効にして、アプリケーションを再実行してみてください。正常に動作する場合は、コードの最適化に問題があると判断できます。

使用法

形式 : -XnoOpt

-XnoOpt を使用すると、効率的でなく、アプリケーションのパフォーマンスに深刻な影響を及ぼすおそれがあるコードをコンパイルし続けることになります。

デフォルト値

-XnoOpt を設定しない場合、コードは通常どおりに最適化されます。

影響を受けるフラグや他のオプション

-XXnoJITInline を使用する場合は、-XnoOpt も使用する必要があります。-XXnoJITInline は、メソッドが最初にコンパイルされるときだけインライン化を無効にします。一緒に -XnoOpt を設定しなければ、コードが最適化されるときにメソッドがインライン化される可能性があります。

例外

なし

 

-Xns

-Xns ではナーサリ サイズを設定します。JRockit JVM でナーサリが使用されるのは、世代別ガベージ コレクション モデルを使用しているときです。つまり、動的なガベージ コレクタが世代別ガベージ コレクション モデルを使用すべきと判断した場合、または静的な世代別コンカレント ガベージ コレクタ (-Xgc:gencon) が選択されている場合です。また、-Xns を使用して、動的なガベージ コレクタ (-XgcPrio) の実行中に静的なナーサリ サイズを設定することもできます。

使用法

形式 : -Xns:<size>[g|G|m|M|k|K]

-Xns をメモリ値と組み合わせます。

次に例を示します。

java -Xns:10m myApp

ナーサリをヒープの 10MB に設定します。

ナーサリ サイズの値は、ヒープに設定された最大値を超えることはできません。

デフォルト値

デフォルト値は、動的なガベージ コレクタ (デフォルトのガベージ コレクタ) を使用するか、静的なガベージ コレクタを選択するかによって異なります。表 2-7 を参照してください。

表 2-7 デフォルトのナーサリ サイズ
リリース
使用オプション
デフォルト値
すべて
-server (デフォルト)
動的 (デフォルトのガベージ コレクタが動的なため)
すべて
-client
なし (-client モードのデフォルトのガベージ コレクタがシングル スペースなため)
すべて
-Xgc:gencon または -client と併用する -Xgc:genpar
2 MB
すべて
-Xgc:gencon
10 MB x ハードウェア スレッド数 (ヒープ サイズの最大 25%)
R27.3 以降
-Xgc:genpar
動的
すべて
-Xgcprio:throughput
動的
すべて
-Xgcprio:pausetime
動的

影響を受けるフラグや他のオプション

なし

例外

-Xns を使用する場合は、以下の例外に注意してください。

 

-XpauseTarget

このオプションでは、短い休止時間を最適化する動的なガベージ コレクション モード (-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

注意 : -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 の監視および処理を行いません。

使用法

形式 : -Xrs

JRockit JVM をサービスとして実行している場合 (Web サーバのサーブレット エンジンなど)、起動時にこのコマンドを入力すると、JVM は CTRL_LOGOFF_EVENT イベントまたは SIGHUP イベントの監視も処理も行わなくなります。

影響を受けるフラグや他のオプション

なし

例外

-Xnohup を指定する場合は、以下の点に注意してください。

 

-Xrunjdwp

このオプションでは、JDWP の JPDA リファレンス実装をロードします。このライブラリはターゲット VM に配置され、JVMDI と JNI を使用してターゲット VM とやり取りします。独立したデバッガ アプリケーションとの通信には、トランスポートと JDWP プロトコルを使用します。

使用法

形式 : -Xrunjdwp:<name1>[=<value1>],<name2>[=<value2>]...

-Xrunjdwp オプションは、さらに表 2-8 に示すいずれかのサブオプションを指定して修飾することができます。

表 2-8 -Xrunjdwp のサブオプション
名前
必須/省略可能
デフォルト値
説明
help
省略可能
N/A
簡単なヘルプ メッセージを出力し、VM を終了する。
transport
必須
なし
デバッガ アプリケーションへの接続に使用するトランスポートの名前。
server
省略可能
「n」
「y」の場合は、デバッガ アプリケーションからの接続をリスンする。それ以外の場合は、指定されたアドレスでデバッガ アプリケーションに接続する。
「y」が指定され、アドレスが指定されていない場合は、デバッガ アプリケーションをリスンするトランスポート アドレスを選択し、そのアドレスを標準出力ストリームに出力する。
address
server=n
の場合は必須、それ以外は省略可能
““
接続用のトランスポート アドレス。server=n の場合は、このアドレスでデバッガ アプリケーションへの接続を試みる。server=y の場合は、このアドレスで接続をリスンする。
launch
省略可能
なし
JDWP の初期化が完了したときに、この文字列で指定されたプロセスを起動する。「Just-In-Time デバッグ」を行うときは、onthrow または onuncaught、あるいはその両方と組み合わせて使用する。「Just-In-Time デバッグ」では、この VM で特定のイベントが発生したときにデバッガ プロセスが起動する。
起動されるプロセスは、独自のウィンドウでは開始されない。多くの場合、起動されるプロセスは小さなアプリケーションで、そのアプリケーションがデバッガ アプリケーションを独自のウィンドウで起動する。
この引数で指定した文字列には、以下の文字列が (空白で区切られて) 追加される。これらの文字列は、起動されたデバッガがこの VM との接続を確立する際に利用される。ここで生成される文字列が実行される。
transport サブオプションの値
address サブオプションの値 (または、値が指定されていない場合は生成されたアドレス)
onthrow
省略可能
なし
指定されたクラスの例外がこの VM で送出されるまで、JDWP ライブラリの初期化を遅らせる。例外クラス名はパッケージで修飾されている必要がある。接続の確立は JDWP の初期化に含まれるので、例外が送出されるまで開始されない。
onuncaught
省略可能
「n」
「y」の場合は、捕捉されなかった例外がこの VM で送出されるまで、JDWP ライブラリの初期化を遅らせる。接続の確立は JDWP の初期化に含まれるので、例外が送出されるまで開始されない。捕捉されなかった例外の定義については、com.sun.jdi.ExceptionEvent の JDI の仕様を参照。
stdalloc
省略可能
「n」
JDWP リファレンス実装では、メモリの割り当てにデフォルトで代替アロケータを使用する。「y」の場合は、標準の C 実行時ライブラリ アロケータが使用される。これは主にテスト用のオプションなので、注意して使用する。代替アロケータを無効にすると、この VM でデッドロックが発生することがある。
strict
省略可能
「n」
「y」の場合は、JVMDI に厳密に準拠していると見なされる。これにより、JVMDI 実装の確認済みのバグに対するすべての回避策が無効になる。これは主にテスト用のオプションなので、注意して使用する。
suspend
省略可能
「y」
「y」の場合、VMStartEvent の中断ポリシーは SUSPEND_ALL になる。「n」の場合、VMStartEvent の中断ポリシーは SUSPEND_NONE になる。

次に例を示します。 

java -Xrunjdwp:transport=dt_socket,server=y,address=8000 myApp

このコマンドは次の処理を実行します。

このコマンドは次の処理を実行します。

このコマンドは次の処理を実行します。

このコマンドは次の処理を実行します。

このコマンドは次の処理を実行します。

このコマンドは次の処理を実行します。

影響を受けるフラグや他のオプション

なし

例外

なし

 

-Xss

-Xss では、スレッド スタック サイズを設定します。スレッド スタックは、各 Java スレッドが内部的に使用するために割り当てられるメモリ領域です。ここにスレッドのローカルの実行状態が格納されます。

使用法

形式 : -Xss<size>[g|G|m|M|k|K]

-Xss をメモリ値と組み合わせます。

次に例を示します。

java -Xss:512k myApp

デフォルトのスタック サイズを 512KB に設定します。

単位を追加しないと、指定したままの値として解釈されます。たとえば、64 は 64 バイトとして解釈されます。64MB や 64KB にはなりません。

デフォルト値

-Xss のデフォルト値は、表 2-9 に示すようにプラットフォームごとに異なります。

表 2-9 -Xss のデフォルト値
プラットフォーム
デフォルト
Windows IA32
64KB
Linux IA32
128KB
Windows x86_64
128KB
Linux x86_64
256KB
Windows IA64
320KB
Linux IA64
1024KB (1MB)
Solaris Sparc
512KB

影響を受けるフラグや他のオプション

なし

例外

なし

 

-XstrictFP

このオプションは、厳密な浮動小数点演算をすべてのクラスのすべてのメソッドでグローバルに有効にします。-XstrictFP を設定すると、JVM は Java 仕様で要求されているより高い精度で、より広い値の範囲を使って計算を行います。-XstrictFP を使用した場合、コンパイラは Java 仕様に厳密に準拠するコードを生成し、どのプラットフォームでもまったく同じ結果が得られるようにします。-XstrictFP を設定しないと、JVM は浮動小数点値をそれほど厳密に適用しません。

このオプションは、Java キーワード strictfp に似ています。ただし、このキーワードはクラス レベルで適用されるのに対し、-XstrictFP はグローバルに適用されます。strictfp の詳細については、「Java Language Specification」を参照してください。

使用法

形式 : -XstrictFP

影響を受けるフラグや他のオプション

なし

例外

なし

 

-Xverbose

-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

表 2-10 -Xverbose のパラメータ
パラメータ
画面への出力
class
ロードされたクラスの名前。サンプル出力は次のようになる。
[INFO ][class ] Initializing bootstrap classes...
[INFO ][class ] created: # 0 java/lang/Object
(/localhome/jrockits/R27.5.0_R27.5.0-110_1.5.0/jre/lib/rt.jar)
[INFO ][class ] 0 java/lang/Object success (0.45 ms)
[INFO ][class ] created: # 2 java/io/Serializable
(/localhome/jrockits/R27.5.0_R27.5.0-110_1.5.0/jre/lib/rt.jar)
[INFO ][class ] 2 java/io/Serializable success (0.08 ms)
codegen
コンパイルされる各メソッドの名前。codegen の冗長出力は次のようになる。
[codegen] 0 : 17.9411 ms
[codegen] 0 68592131 1 java.lang.Object.unlockFatReal_jvmpi (Ljava.lang.Object;Ljava.lang.Thread;I)V: 17.94 ms
[codegen] 1 : 2.0262 ms
[codegen] 0 0 2 java.lang.Object.acquireMonitor(Ljava.lang.Object;II)I: 19.97 ms
[codegen] 2 : 4.4926 ms
[codegen] 0 10 3 java.lang.Object.unlockFat(Ljava.lang.Object;Ljava.lang.Thread;I)V: 24.46 ms
[codegen] 3 : 0.3328 ms
cpuinfo
使用中の CPU に関する技術的な情報。cpuinfo の冗長出力は次のようになる。
[cpuinfo] Vendor: GenuineIntel
[cpuinfo] Type: Original OEM
[cpuinfo] Family: Pentium 4
[cpuinfo] Brand: Intel(R) Pentium(R) 4 Mobile CPU 1.60GHz
[cpuinfo] Supports: On-Chip FPU
[cpuinfo] Supports: Virtual Mode Extensions
[cpuinfo] Supports: Debugging Extensions
[cpuinfo] Supports: Page Size Extensions
exceptions
例外の型とメッセージを表示する (一般的な型の例外は対象外)。exceptions の冗長出力は次のようになる。
[excepti][00002] java/lang/NumberFormatException: null
exceptions=debug
例外の型とメッセージを表示する (一般的な型の例外は対象外)。スタックトレースも表示。exceptions=debug の冗長出力は次のようになる。
[excepti][00002] java/lang/NumberFormatException: null
at java/lang/Integer.parseInt(Ljava/lang/String;I)I(Integer.
java:415)
at java/lang/Integer.<init>(Ljava/lang/String;)V(Integer.
java:620)
at sun/net/InetAddressCachePolicy.<clinit>()V
(InetAddressCachePolicy.java:77)
at jrockit/vm/RNI.c2java(IIII)V(Native Method)
at jrockit/vm/RNI.generateFixedCode(I)I(Native Method)
at java/net/InetAddress.<clinit>()V(InetAddress.java:640)
at jrockit/vm/RNI.c2java(IIII)V(Native Method)
at jrockit/vm/RNI.generateFixedCode(I)I(Native Method)
at java/net/InetSocketAddress.<init>(Ljava/lang/String;I)V
(InetSocketAddress.java:124)
at java/net/Socket.<init>(Ljava/lang/String;I)V
(Socket.java:178)
at Ex.main([Ljava/lang/String;)V(Ex.java:5)
at jrockit/vm/RNI.c2java(IIII)V(Native Method)
--- End of stack trace
exceptions=trace
debug の場合と同じ情報を表示するが、一般的な型の例外も表示対象となる。exceptions=trace の冗長出力は -Xverbose:exceptions=debug を指定した場合と同様だが、以下の型の例外の情報も出力される。
  • java.util.EmptyStackException
  • java.lang.ClassNotFoundException
  • java.security.PrivilegedActionException
load
ロードされた各 Java またはネイティブ ライブラリの名前。
[INFO ][load ] opened zip
/localhome/jrockits/R27.5.0_R27.5.0-110_1.5.0/jre/lib/rt.jar
[INFO ][load ] opened zip
/localhome/jrockits/R27.5.0_R27.5.0-110_1.5.0/jre/lib/jsse.jar
[INFO ][load ] opened zip
/localhome/jrockits/R27.5.0_R27.5.0-110_1.5.0/jre/lib/jce.jar
[INFO ][load ] opened zip
/localhome/jrockits/R27.5.0_R27.5.0-110_1.5.0/jre/lib/charsets.jar
[INFO ][load ] Loaded native library:
/localhome/jrockits/R27.5.0_R27.5.0-110_1.5.0/jre/lib/i386/libverify.so
[INFO ][load ] Loaded native library:
/localhome/jrockits/R27.5.0_R27.5.0-110_1.5.0/jre/lib/i386/libjava.so
[INFO ][load ] Loaded native library:
/localhome/jrockits/R27.5.0_R27.5.0-110_1.5.0/jre/lib/i386/native_threads/libhpi.so
[INFO ][load ] Loaded native library:
/localhome/jrockits/R27.5.0_R27.5.0-110_1.5.0/jre/lib/i386/libzip.so
gcpause
-Xverbose:gcpause を指定すると、-XgcPause と同じ出力になる。
gcreport
-Xverbose:gcreport を指定すると、-XgcReport と同じ出力になる。
memdbg
メモリ情報の出力を有効にし、さらにメモリ デバッグのための特別の memdbg 出力も表示する。memdbg の冗長出力は次のようになる。
[memory ] 12.875: nursery GC 89648K->89716K (89716K), 3.296 ms
[memdbg ] nursery GC 291: promoted 1510 objects (69744 bytes) in 3.296 ms
[memdbg ] Page faults before GC: 36784, page faults after GC: 36800, pages in heap: 22429
[finalizer] (YC) Pending finalizers 0->0
[memdbg ] old collection 7 started
[memdbg ] Compacting 8 heap parts at index 112 (type 2) (exceptional 0)
[memdbg ] starting parallel marking phase
[memdbg ] ending marking phase [memdbg ] current generational GC work score: 0.142956
[memdbg ] last single generational GC work score: 0.081486
[memdbg ] current error: -0.042956
[memdbg ] previous nursery size: 736760
[memdbg ] requested nursery size: 711984
[memdbg ] starting parallel sweeping phase
[memdbg ] ending sweeping phase
[memory ] 11.841-12.025: GC 89716K->67088K (89716K), 184.000 ms
[memdbg ] Page faults before GC: 36827, page faults after GC: 37036, pages in heap: 22429
[finalizer] (OC) Pending finalizers 0->0
memdbg を -XgcPrio: throughput と共に指定した場合
メモリ情報の出力を有効にし、さらにメモリ デバッグのための特別の memdbg 出力も表示する。アプリケーションのスループットを重視するように最適化された動的なガベージ コレクタ (-XgcPrio:throughput) を実行する JVM で、memdbg を指定した場合、レポートは次のようになる。
[memdbg ] nursery GC 3: promoted 22788 objects (1246K) in 28.472 ms
[memdbg ] Page faults before GC: 24768, page faults after GC: 25288, pages in heap: 19170
[finaliz] (YC) Pending finalizers 0->0
[memdbg ] old collection 2 started
[memdbg ] OC reasons: Large obj: 1 (4021248 bytes), TLA: 1, Promotion: 0, GCTrigger: 1, SystemGC: 0, Other: 0
[memdbg ] Compacting 8 heap parts at index 0 (type 1) (exceptional 0)
[memdbg ] starting parallel marking phase
[memdbg ] ending marking phase
[memdbg ] current generational GC work score: 0.266484
[memdbg ] last single generational GC work score: 0.000000
[memdbg ] current error: -0.166484
[memory ] Changing GC strategy to single generation, parallel mark and parallel sweep
[memdbg ] starting parallel sweeping phase
[memdbg ] ending sweeping phase
[memdbg ] expanding the heap from 74 MB to 87 MB
[memory ] 15.882-16.157: GC 76680K->69203K (89716K), 275.413 ms
[memdbg ] Page faults before GC: 25288, page faults after GC: 25765, pages in heap: 22429
[finaliz] (OC) Pending finalizers 0->0
memory;
gc
メモリ管理システムに関する以下のような情報。
  • コレクションの開始時間 (JVM が起動してからの秒数)
  • コレクションの終了時間 (JVM が起動してからの秒数)
  • コレクション前にオブジェクトで使用されているメモリ (KB)
  • コレクション後にオブジェクトで使用されているメモリ (KB)
  • コレクション後のヒープ サイズ (KB)
  • コレクションの合計時間 (秒数またはミリ秒数)
  • コレクション中の合計休止時間 (ミリ秒数)
-Xverbose:memory または -Xverbose:gc で表示される情報は、使用するガベージ コレクタのタイプによって異なる。
memory;
gc
gencon の場合
世代別コンカレント コレクタ (-Xgc:gencon) を実行する JVM で、memory または gc を指定する場合、レポートは次のようになる。
[memory ] GC strategy: gencon
[memory ] heap size: 65536K, maximal heap size: 785672K, nursery size: 16384K
[memory ] <s>-<end>: GC <before>K-><after>K (<heap>K), <pause> ms
[memory ] <s/start> - start time of collection (seconds since jvm start)
[memory ] <end> - end time of collection (seconds since jvm start)
[memory ] <before> - memory used by objects before collection (KB)
[memory ] <after> - memory used by objects after collection (KB)
[memory ] <heap> - size of heap after collection (KB)
[memory ] <pause> - total pause time during collection (milliseconds)
[memory ] 1.069: parallel nursery GC 24995K->24810K (65536K), 40.038 ms
[memory ] 1.535: parallel nursery GC 46818K->46701K (65536K), 31.319 ms
[memory ] 8.698-9.247: GC 48085K->46437K (65536K), 230.190 ms
[memory ] 9.252-9.915: GC 49055K->55834K (76680K), 216.105 ms
[memory ] 9.928: parallel nursery GC 63287K->63287K (76680K), 20.282 ms
memory;gc
singlecon の場合
シングルスペース コンカレント コレクタ (-Xgc:singlecon) を実行する JVM で、memory または gc を指定する場合、レポートは次のようになる。
[memory ] GC strategy: singlecon
[memory ] heap size: 65536K, maximal heap size: 785672K
[memory ] <s>-<end>: GC <before>K-><after>K (<heap>K), <pause> ms
[memory ] <s/start> - start time of collection (seconds since jvm start)
[memory ] <end> - end time of collection (seconds since jvm start)
[memory ] <before> - memory used by objects before collection (KB)
[memory ] <after> - memory used by objects after collection (KB)
[memory ] <heap> - size of heap after collection (KB)
[memory ] <pause> - total pause time during collection (milliseconds)
[memory ] 30.220-30.693: GC 65058K->55006K (76680K), 101.591 ms
[memory ] 30.749-31.290: GC 76680K->73168K (89716K), 90.350 ms
[memory ] 31.297-31.904: GC 79089K->89716K (104968K), 2.386 ms
memory;
gc
parallel の場合
パラレル コレクタ (-Xgc:parallel) を実行する JVM で、memory または gc を指定する場合、レポートは次のようになる。
[memory ] GC strategy: parallel
[memory ] heap size: 65536K, maximal heap size: 785672K
[memory ] <s>-<end>: GC <before>K-><after>K (<heap>K), <pause> ms
[memory ] <s/start> - start time of collection (seconds since jvm start)
[memory ] <end> - end time of collection (seconds since jvm start)
[memory ] <before> - memory used by objects before collection (KB)
[memory ] <after> - memory used by objects after collection (KB)
[memory ] <heap> - size of heap after collection (KB)
[memory ] <pause> - total pause time during collection (milliseconds)
[memory ] 1.563-1.805: GC 65536K->55018K (76680K), 242.030 ms
[memory ] 1.871-2.114: GC 76680K->73161K (89716K), 242.675 ms
[memory ] 2.167-2.478: GC 89716K->86478K (104968K), 310.974 ms
memory;
gc
-Xgcprio: throughput の場合
アプリケーションのスループットを重視するように最適化された動的なガベージ コレクタ (-XgcPrio:throughput) を実行する JVM で、memory または gc を指定した場合、レポートは次のようになる。
[memory ] GC strategy: System optimized over throughput (initial strategy singleparpar)
[memory ] heap size: 65536K, maximal heap size: 785672K
[memory ] <s>-<end>: GC <before>K-><after>K (<heap>K), <pause> ms
[memory ] <s/start> - start time of collection (seconds since jvm start)
[memory ] <end> - end time of collection (seconds since jvm start)
[memory ] <before> - memory used by objects before collection (KB)
[memory ] <after> - memory used by objects after collection (KB)
[memory ] <heap> - size of heap after collection (KB)
[memory ] <pause> - total pause time during collection (milliseconds)
[memory ] Changing GC strategy to generational, parallel mark and parallel sweep
[memory ] 1.669-1.904: GC 65536K->54455K (76680K), 234.978 ms
[memory ] 1.923: parallel nursery GC 66150K->67136K (76680K), 105.995 ms
[memory ] 2.039: parallel nursery GC 71236K->71203K (76680K), 58.620 ms
[memory ] 2.107: parallel nursery GC 75303K->76680K (76680K), 36.650 ms
[memory ] Changing GC strategy to single generation, parallel mark and parallel sweep
[memory ] 2.164-2.482: GC 76680K->69340K (89716K), 318.158 ms
opt
最適化されるすべてのメソッドの情報。opt の冗長出力は次のようになる。
[opt ] 280 2434 0 ObjAlloc.main([Ljava.lang.String;)V: 0.00 ms
[opt ] 0 : 9.8996 ms
referents
古い世代の各ガベージ コレクションごとの参照オブジェクトと、その参照オブジェクトが指している参照。-Xverbose:referents は、R27.2 より前の JRockit JVM バージョンの -Djrockit.verboserefs オプションに相当する。
各参照型は参照クラスおよびリファレントごとに分類される。ハンドルの場合は、参照は存在しないので、リファレントのみが表示される。表示されるさまざまなカウンタの値は、存在する各型のインスタンスの数を示しており、それらが到達可能であるかどうか (クリアされているかどうか) も確認できる。
レポートのヘッダ/フッタには、どのタイプのコレクションが実行されたのかが表示される。直前に実行された古いコレクションの完了時からの経過時間と、その時点での空きメモリのサイズも報告される。また、ソフト参照が存在する場合は、コレクションの対象となったソフト到達可能なリファレントが明示され、そのコレクションを実行した判断基準として、それらのリファレントが get() の呼び出しを通じて最後に参照された時点からの経過時間が表示される。
このログ モジュールのパフォーマンス オーバーヘッドは高い。
refobj
ガベージ コレクションごとの参照オブジェクトとハンドルに関する情報。info レベルの出力では、さまざまな種類の参照オブジェクトと、そのうちのいくつが 「アクティブ化」 されているかが要約される。参照オブジェクトは、その参照オブジェクトの種類の到達可能性要件が満たされたときにアクティブ化される。アクティブ化されると、メモリ管理システムが、参照の種類に応じて、オブジェクトを参照キューに入れるか、ファイナライズを待機するキューに入れる。
debug レベルでは、このモジュールは、以前に -Xverbose:referents によって表示されていた情報が改善されたバージョンを表示する。
このログ モジュールの info レベルのパフォーマンス オーバーヘッドは小さい。debug レベルのパフォーマンス オーバーヘッドは大きい。
このモジュールは、JRockit JVM R27.5 以降のリリースで使用できる。
stackoverflow
スタック オーバーフローの発生時に、そのエラー情報を表示する。その際には、通常、数ページにわたる大量の情報が出力されるが、内容的には同じ情報が延々と繰り返し表示される場合が多くなる。これは、スタック オーバーフローの発生時には非常に大量のスタック トレースが生成され、このパラメータを指定した場合には、そのすべてが出力されるためである。
starttime
JRockit JVM が起動されたときの System.currentTimeMillis() および System.nanoTime() の値。これらを使用すると、異なるプロセス間のログ出力を相関させることができる。starttime の冗長出力は次のようになる。 
[startti] VM start time: 1152871839957 millis 171588375730523 nanos
この例の説明は次のとおり。
  • millis は、1970 年 1 月 1 日 0 時 (協定世界時) からの経過時間 (ミリ秒単位)。この値は、System.currentTimeMills() が返す値と同じ。
  • nanos は、10 億分の 1 秒 (ナノ秒) の単位で時間を測定する。ただし、オペレーティング システムごとに最も効率的な測定方法を使用できるように、nanoTime() の測定開始時刻は指定されていない。この値は、System.nanoTime() が返す値と同じ。
systemgc
JRA の記録および -Xverbose:memdbg の出力で System.gc() の呼び出しによって開始されたガベージ コレクションまたは「other」としてマークされているために開始されたガベージ コレクションに対する通知を行う。たとえば、ガベージ コレクションを暗黙的に開始する JMAPI 関数や診断コマンド runsystemgc の呼び出しなど。
System.gc() の直接呼び出しによって開始されるガベージ コレクションは、次のような冗長出力になる。
[INFO ][sysgc ] GC requested by thread 1
この出力のスレッド番号は、ガベージ コレクションを要求するスレッドのスレッド ID である。
その他の方法によって開始されるガベージ コレクションの出力には、ガベージ コレクションの理由が出力される。たとえば、次のようになる。
[INFO ][sysgc ] GC triggered for reason: Set Nursery Size

注意 : JRockit JVM R27.3 以前のバージョンでは、-Xverbose:systemgc のすべての出力が同様になる。さらに、-Xverbose:systemgc によって出力され、「other」として扱われる一部のガベージ コレクションは出力されなかった。
timing
タイマーの時間単位。および、Linux では、時間値を取得するために使用されるメソッド。これは、System.nanoTime() メソッドによって使用されるタイマーの時間単位。
Windows での冗長タイミング レポートの例は次のとおり。
[INFO ][timing ] Counter timer using resolution of 1779720000Hz
verboserefs
referents と同じ出力になる。

ログ レベル

ログ レベルは、ログに記録される情報のレベルを指定します。JRockit JVM では、表 2-11 に示されている 6 種類のログ レベルを使用します。

表 2-11 Xverbose のログ レベル
ログ レベル
説明
quiet
ログなし。メッセージもエラーも生成されない。
error
エラー メッセージだけがログに記録される。
warn
エラーに加えて警告メッセージもログに記録される。まだ低レベルのログ レベルであり、warn は、通常、後でエラーを引き起こすおそれがあるイベントを警告するのに使用される。
info
info レベルでは、エラーと警告が記録されるだけでなく、JRockit JVM の現在の状態や各種の JVM イベントに関する情報メッセージもログに記録される。これは、引数を指定せずに -Xverbose を使用する場合のデフォルトのログ レベルである。
debug
debug は JRockit JVM の動作の詳細な情報でメッセージを登録します。通常、debug が提供する情報は日常のログとしては過多だが、デバッグには役立つ。
trace
trace を指定すると、非常に冗長なログが記録される。このレベルは、デバッグ レベルが生成する情報でも問題が解決できないモジュールで使用する。一般に、trace は、1 分あたり最大 10 ～ 100 ページ分のテキストを記録する必要がある場合に使用する。

影響を受ける他のフラグやオプション

-Xverbose を設定しないと、以下のオプションは機能しません。

例外

なし

 

-XverboseDecorations

JRockit JVM が冗長な出力に追加する「デコレーション」を設定するには、このオプションを使用します。デコレーションは、冗長な出力にさらに意味を持たせるために使用される、通常はシステム関連の追加情報です。メッセージの生成元のモジュールの名前や、現在の JRockit JVM セッションが開始してからの経過時間 (ミリ秒単位) などがその例です。

使用法

形式 : -Xverbosedecorations=<decoration names>

次に例を示します。

起動時に次のように指定します。 

java -Xverbose:gcpause -XverboseDecorations=timestamp,module myApp

上の指定によって、出力に以下のデコレーションが含まれます。

注意 : control-break ハンドラ verbosity と引数 decorations を一緒に使用することもできます。

指定できるデコレーションを表 2-12 に示します。

表 2-12 冗長出力のデコレーション
デコレーション
説明
level
メッセージのログ レベルを出力する。
millis
1970 年 1 月 1 日 0 時 (協定世界時) からの経過時間 (ミリ秒単位) を出力する。この値は、System.currentTimeMills() が生成する値と同じ。
millisstart
JRockit JVM が開始してからの経過時間 (ミリ秒単位) を出力する。
module
メッセージの生成元のモジュールを出力する。-Xverbose への引数と同じ。
nanos
System.nanoTime() が返す値と同じ値を出力する。「nanoTime」は、10 億分の 1 秒 (ナノ秒) の単位で時間を測定する。ただし、オペレーティング システムごとに最も効率的な測定方法を使用できるように、nanoTime() の測定開始時刻は指定されていない。
nanosstart
JRockit JVM が開始してからの経過時間 (ミリ秒単位) を出力する。
pid
プロセス ID を出力する。
threadid
スレッドのインデックスを出力する。これは、スレッド ダンプ内で idx が提供する値と同じ値。
timestamp
理解しやすい形式のタイムスタンプを出力する。これは、-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 オプションも設定されている場合にのみ使用できます。

例外

なし

 

-XverboseLog

このオプションでは、Oracle JRockit JVM からのメッセージ (冗長出力やエラー メッセージなど) を stderr ではなく、指定したファイルに出力します。

使用法 

形式 : -Xverboselog:myFile.txt

ファイル名と拡張子を指定してこのコマンドを使用すると (myFile.txt など)、JVM は指定したファイルにロギング情報を書き込みます。

次に例を示します。 

java -Xverbose:gcpause -Xverboselog:verboseText.txt myApp

このコマンドでは、クラス myApp の冗長なロギング情報が verboseText.txt という名前のファイルに書き込まれます。

影響を受けるフラグや他のオプション

このオプションは、冗長ロギングを有効にする -Xverbose オプションが設定されている場合にのみ機能します。

例外

このオプションを指定すると、画面には情報が出力されません。

 

-XverboseTimeStamp

このオプションは、冗長出力にタイムスタンプを追加します。イベントのログを記録するときに役立ちます。

使用法

形式 : -XverboseTimeStamp

-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 を使用して有効になっている場合、または実行時に有効になっている場合にのみ適用されます。

例外

なし

 

-Xverify

このオプションを使用すると、バイトコードの正確性を手動で検証することができます。これらのチェックを実行時に繰り返し行わずに、クラスのロード時に一度だけ行うことにより、実行時の効率を高めることができます。

使用法

形式 : -Xverify:<param>

このオプションを表 2-13 に示すいずれかのパラメータと組み合わせます。

表 2-13 -Xverify のパラメータ
<param>
説明
none
バイトコードを検証しない。このパラメータを使用すると、起動時間が短縮されるが、Java による一部の保護機能を利用できなくなる。
remote
ネットワーク経由でロードされるクラスのみを検証する。
all
すべてのクラスを検証する。

デフォルト値

このオプションを使用しない場合、デフォルトではネットワーク経由でロードされるクラスのみが検証されます (-Xverify:remote)。

影響を受けるフラグや他のオプション

なし

例外

なし


  ページの先頭       前  次