2018.03.08
JVM Options
概要
JVM Optionをしるべき理由
Java言語はハードウェア/OSに独立的です。すなわち、Javaで作成されたApplicationは何の修正なしにJVMが駆動可能などんなOSでも動作します。 しかし、これは“動作”の独立性であるだけであり、“性能”の独立性でありません。
特定OSの特定JDKバージョンで何の性能問題なく駆動されたApplicationが違うOSや他のバージョンのJDKでは深刻なパフォーマンスの問題を経験する事例がしばしばあります。Java言語とBytecodeは独立性を有していますが、Bytecodeを実行するJVMはそうではないためです。このような種類の性能問題を解決するには、JVMが提供するOptionsにはどんなものがあってOptionの適用によりどんな差が現れるのか正確に理解しなければならないのです。
Standard vs.Non-Standard Option
Standard Optionは、JVMの標準です。つまりSun HotSpot JVM、IBM JVM、BEA JRockit JVM、HP HotSpot JVMなど、すべてのJVMが同じOptionを提供します。
一方、Non-Standard Optionは、JVMの標準ではありません。したがってJVMのバージョンとOSの種類に応じて存在するかどうかが決まります。また、いつでも追加したり、なくなることもあります。このような面からNon-Standard Optionは悩みのタネとも言えます。しかし、次のような点で必要な存在でもあります。
・JVMの駆動に必要な設定値（Configuration Value）を指定することができる点。 ・パフォーマンスの向上に必要なParameterの値を指定することができる点。 ・Bugや誤動作によるWorkaroundに活用することができる点。
Non-Standard Optionを知らなくてもJava Applicationを作成する事には全く問題がないこともあります。しかし、小さな誤動作や性能低下だけ発生してもNon-Standard Option助けなしでは解決できない場合が多くあります。したがってシステム管理者や開発者は重要なNon-Standard Optionに対してある程度理解していなければなりません。
Non-Standard Optionは、次の2つのカテゴリに分類されます。
・-X Option：一般的なNon-Standard Optionです。 Macro面でのJVMの制御機能を提供します。 -X Optionは、JVMごとに異なりますが、一部のOptionは、まるでStandard Optionのように使用されます。 ・-XX Option：-X Optionよりも細かい制御機能を提供します。 Micro面でのJVMの機能を提供します。 細かいパフォーマンスチューニングやバグのWorkaroundのために主に活用されます。 -XX Optionは、JVMのタイプに応じて全く違います。
Option指定する
JVM Optionを指定する方法の例は、以下の通りです。
1.単一値：-client Optionのようにオプションを指定すると、それ自体で意味を持地ます。
2.サイズ（Size）：-Xmx1024mのようにサイズ（K、M、G）を指定します。
3.数字（Int）：-XX：SurviorRatio=10のように数値を指定します。
4.文字列（String）：-agentlib：hprof= cpu= samplesのように文字列を指定します。
5.Boolean：-XX：+ PrintGCDetailsあるいは-XX：-PrintGCDetailsのように+/-を用いて
有効/無効にするかどうかを指定します。
Sun HotSpot JVM（1.5基準）
Standard Options
| Option | Description |
| -client | Client HotSpot JVMを使用する。Client HotSpot JVMは、Desktop用Applicationを動作するのに有利です。パフォーマンスの最適化（Optimization）のプロセスを簡略化することで、Applicationの開始時間を最小限に抑えています。 |
| -server |
Server HotSpot JVMを使用する。Server HotSpot JVMは、Server用のApplicationを駆動するのに有利である。パフォーマンスの最適化（Optimization）に必要なすべてのプロセスを最大限に実行する。Applicationの開始時間は遅いが、一定時間がたつとClient HotSpot JVMに比べてはるかに優れた性能を保証します。 |
（参考）Jdk 1.5からServer-Classマシンである場合には、-serverオプションが基本適用されます。 Server-Classマシンと2個以上のCPUと2G以上のメモリを搭載したマシンを意味します。
-d3232bit JVMを使用する場合： 32bit JVMは、メモリを最大2Gまで使用することができます。一方、一般的な実行性能64bit JVMに比べて優れたケースが多くなります。したがって、大きなサイズのJava Heapを使用していない場合には、たとえ64bitマシンであっても32bit JVMを使用することをお勧めしています。
-d6464bit JVMを使用する場合： 64bit JVMで使用可能なメモリのサイズは、実質的に制限がありません。大型Applicationの場合、数G〜数十GのJava Heapを使用している場合が多くあります。
-agentlib：[=] Native Agent Libraryをロードします。 Native Agent LibraryとJVMPI/JVMTIを実装したLibraryを意味し、C/C ++で実装されます。 JVMは、Unix/Linuxではlib.soファイルが、Windowsでは.dllファイルを探索します。これらのファイルは、現DirectoryやPATH変数に登録されたDirectoryに存在しなければなりません。
（参照）JDK 1.4まではHProfを実行させるための-Xrunhprof：option = valueオプションを使用します。 JDK 1.5から-Xagentlib：hprof = option = valueオプションが推奨されます。 -Xrunhprofオプションは今後なくなることが可能性があります。
-agentpath：[=] – agentlibオプションと同じ機能です。 Library名の代わりにFull Path名を使用します。
-javaagent：[=] Java Agent Libraryをロードします。 Java AgentはNative AgentがC/C ++で実装されているのとは異なり、Javaで実装されています。 java.lang.instrument Packageを使用してJava Agentを実装する必要なInterfaceが提供されます。Java AgentはBCIを介して、RuntimeにClassのBytecodeを変更する方法を使用してタスクを実行します。
Non-Standard Options (-X)
| Option | Description |
| -Xbootclasspath[/a|/p]: |
Boot class pathを制御します。/aオプションはBoot class pathの一番後にAppend、/pオプションは一番前にPrependします。一般的な環境ではBoot class pathを制御する必要がありません。 Java Core Library(rt.jarなど)等に対してReverse Engineeringを遂行して行動方式を変更しようと思う場合に主に活用されます。 |
| -xcheck:jni | |
| -Xint | IntepreterモードでだけByteCodeを実行します。 Interpreterモードで実行される場合にはJIT Compile機能が動作しません。 このオプションを有効にすると、実行速度によって多少低下することができます。 したがってHotSpot Compilerのバグで問題が生ずる時だけ使用が推奨されます。 |
| -Xnoclassgc | Class Garbage Collectionを実行しません。 |
| -Xloggc: | GC Logを記録するファイル名を指定します。 ファイル名を指定しなければStandard OutでもStandard Errorコンソールに出力される。 主に-XX:+PrintGCTimeStamps,-XX:+PrintGCDetailsオプションのように使われます。 |
| -Xmixed | MixedモードでByteCodeを実行します。 HotSpot JVMのDefault動作方式であり、-Xintオプションと相互排他的なオプションです。 |
| -Xmn | Young Generationが居住するNew Spaceの大きさを指定します。 ほとんどの場合このオプションよりは-XX:NewRatioオプションでも-XX:NewSizeオプションをたくさん使います。 |
| -Xms |
Java Heapの最初の大きさ(Start Size)を指定します。 Java Heapは-Xmsオプションに指定した大きさで始めて最大-Xmxオプションに指定した大きさだけに大きくなります。 Sun HotSpt JVM系列では最初の大きさと最大サイズを同一に付与することを推奨します。 大きさの動的な変更によるオーバーヘッドを最小化するためです。 |
| -Xmx | Java Heapの最大サイズ(Maximum Size)を指定します。 Java Heapは-Xmsオプションに指定した大きさで始めて最大-Xmxオプションに指定した大きさだけに大きくなります。 Sun HotSpt JVM系列では最初の大きさと最大サイズを同一に付与することを推奨します。 大きさの動的な変更によるオーバーヘッドを最小化するためです。 |
| -Xrunhprof[:help][:option=value,…] | HProf(Heap and CPU Profiling Agent)を実行します。 HProfはJVMPI/JVMTIを利用して具現されたSample Profilerです。Sampleに過ぎないのですが、多くの場合HProfだけでも非常に有用な情報を得ることができます。 |
| -Xrs | OS Signal使用を最小化します。 例えば、このオプションをオンにするとkill-3[pid]コマンドを実行してもThread dumpが発生しません。 |
| -Xss | 個別ThreadのStack Sizeを指定します。 例えばThread Stack Sizeが1Mで、Threadが最大100個活性化するならば、最大100Mのメモリーを使うことになります。 多くの場合基本値(Default)をそのまま使うことが望ましいです。多数のThreadを使うApplicationの場合Thread Stackによるメモリー要求量が高まって、これによってOut Of Memory Errorが発生する可能性があります。 このような場合には-Xssオプションを利用してThread Stack Sizeを減らさなければなりません。 |
Non-Standard Options (-XX)
-XXオプションのうちBoolean型は接頭語で+を付ければ活性化(Enable),-を付ければ非活性化(Disable)を意味します。
| Option | Default | Description |
| -XX:+AggressiveHeap | False | 言葉どおりHeapをAggressive(攻撃的)するように使うオプションです。 このオプションが活性化すればJVMは現在ApplicationをMemory-Intensiveしたことと見なしてHeap空間を最大限使うように関連した他のオプション値を決定します。たとえばUseParallelGCオプションを活性化させて、Java Heapの大きさをPhysical Memoryの最大値に近く設定します。 このオプションは、一般的に使われません。 多くの場合、個別的なオプションを利用してもう少し細かいチューニングを試みます。 |
| -XX:+CMSClassUnloadingEnabled | False | CMS CollectorはPermanent GenerationについてGC処理を実行せず、ClassメタデータのUnloading作業も実行していません。したがってApplicationの性質上、多くのClassを動的に生成してLoadingする場合には、Permanent GenerationでOut Of Memory Errorが発生することがあります。このような場合には、このオプションと一緒にCMSPermGenSweepingEnabledオプションを使用してPermanent GenerationのGC作業とClass Unloading作業を活性化します。JDK1.5までは、この両方のオプションを有効にする必要なClass Unloadingが行われます。JDK1.6からCMSPermGenSweepingEnabledオプションを有効にしなくても、このオプションが機能します。 |
| -XX:CMSFullGCsBeforeCompaction= | -1 | CMS CollectorでCompaction（圧縮）を実行する前に、Full GCを実行する回数を指定します。一般的なFull GCはCompaction作業を伴います。一方、CMS CollectorのFull GCはCompactionを実行していません。これにより、HeapのFragmentationが発生することがありますが、Full GCによるPause Timeを最小限に抑えることができるという長所があります。 |
このオプションは、Compactionの発生時点を制御する役割をします。例えば、この値が「1」である場合には、Concurrent Full GCがまだ終了していない時点で、新しいConcurrent Full GCの操作が開始されると、（1）、Compactionが伴います。もしこの値が「0」である場合には、Concurrent Full GCは、「常に」Compactionを伴います。したがってCMS Collectorを使用している環境では、Heap Fragmentationによる問題が発生した場合には、「0」の値を付与することがWorkaroundになることがあります。
-XX：+ CMSIncrementalModeFalseFull GC作業をIncremental（造花方向）に進行します。一般的に、CMS CollectorはOld Generationがある程度以上占有されると、Concurrent Full GCの操作を開始します。一方、このオプションを有効にすると、Old Generationの使用率とは無関係に、バックグラウンドで徐々に（Incremental）Old GenerationのGC処理を実行します。このオプションを使用すると、CMSInitiatingOccupancyFractionオプションは無視されます。
このオプションを有効にするとThroughputは多少減り、Response Timeはいくつかの改善される傾向があります。したがってGC作業Pauseをより抑えたい場合に使用することができます。
-XX：CMSInitiatingOccupancyFraction=-1CMS Collectionが開始されるしきい値を決定します。もしこの値が “50”の場合Old Generationが50％以上使用されると、Concurre Full GCが開始されます。この値のデフォルト値は「-1」です。この場合には、CMSTriggerRatioオプションとMinHeapFreeRatioオプションがしきい値として使用されます。しきい値の計算式は次の通りです。
Start Ratio=100-MinHeapFreeRatio（=40）+ MinHeapFreeRatio（=40）*（CMSTriggerRatio（=80）/100）=92
つまり、CMSInitiatingOccupancyFractionオプションが指定されていない場合、Old Generationが92％程度使用すると、Concurrent Full GCが開始されます。
このオプションを指定すると、50％から開始して、オプションで指定された値まで徐々にしきい値を調整します。もししきい値を固定しようとする場合には、UseCMSInitiatingOccupancyOnlyオプションを有効にする必要があります。
このオプションの値が小さい場合CMS Collectionがそれだけ早く動作するため、Promotion FailureによるStop The World GC作業が発生する確率がそれだけ減少します。
-XX：+ CMSPermGenSweepingEnabledFalseCMS Collectorは、基本的にPermanent GenerationのCollectionを実行していません。したがって、多くの数のClassをLoadingする場合Out Of Memory Errorが発生することができます。このオプションを有効にするとPermanent GenerationのCollectionを実行します。JDK 1.5までは、このオプションと一緒にCMSClassUnloadingEnabledオプションを有効にする必要動作します。-XX：CompilerCommandFile = .hotspot_compilerCompiler Command Fileの位置を指定します。-XX：+ DisableExplicitGCFalseSystem.gc呼び出しによるExplicit GCを無効にします。RMIによるExplicit GCまたはApplicationでのExplicit GCを根本的に防止しようとする場合に使用されます。-XX：GCHeapFreeLimit = 5Parallel Collectorを使用すると、GCの間にOut Of Memory Errorの発生を防止するのに役立ちます。GCで確保すべきFree Spaceの下限を決定します。この値は、Max HeapサイズのFree領域の割合で、既定値は「5」です。つまりParallel Collection後確保すべきFree領域のサイズは、少なくともMax Heapサイズの5％以上になるように保証することです。-XX：GCTimeLimit = 90Parallel Collectorを使用すると、GCの間にOut Of Memory Errorの発生を防止するのに役立ちます。全JVM実行時間比Parallel Collection実行時間の上限を決定します。デフォルトは「90」です。つまりParallel Collection全体実行時間の90％まで使用できるようになります。-XX：+ HeapDumpOnOutOfMemoryErrorFalseOut Of Memory Errorが発生した場合Heap DumpをFileに記録します。JDK 1.6からサポートされているオプションです。-XX：MaxGCMinorPauseMillis = NoneMinor GCによるPause Timeをms以下になるHeapサイズとその他のオプションを自動的に調整する機能です。この値は、目標値（Target）で固定値ではありません。Minor GCによるPause Timeが長い場合にWorkaroundとして使用することができます。-XX：MaxGCPauseMillis = NoneGCによるPause Timeをms以下になるHeapサイズとその他のオプションを自動的に調整する機能を有します。 MaxGCMinorPauseMillisオプションと同様に目標値としての役割をはたします。GCによるPause Timeが長い場合にWorkaroundとして使用することができます。-XX：MaxHeapFreeRatio = 70Heap Shrinkageを実行するしきい値を指定します。たとえば、この値が70であればHeapのFreeスペースが70％以上になるとHeapサイズが縮小されます。 MinHeapFreeRatioオプションと一緒にHeapのサイズ調整を担当します。-XX：MaxNewSize = NoneYoung Generationの最大サイズを指定します。 Young Generationの開始サイズはNewSizeオプションによって指定されます。-XX：MaxPermSize = NonePermanent Generationの最大サイズを指定します。 Permanent Generationの開始サイズはPermSizeオプションによって指定されます。多くのClassをLoadingするApplicationはPermSizeとMaxPermSizeオプションを利用してPermanent Generationのサイズを大きくしてくれる方が良いのです。Permanent Generationのサイズが小さい場合には、Out Of Memory Errorが発生することができます。-XX：MinHeapFreeRatio = 40Heap Expansionを実行するしきい値を指定します。たとえば、この値が40であればHeapのFreeスペースが40％未満になると、Heapサイズが拡大されます。 MaxHeapFreeRatioオプションと一緒にHeapのサイズ調整を担当します。-XX：NewRatio = OS / JDK Versionごとに異なりYoung GenerationとOld Generationの割合を決定します。たとえばこの値が2の場合Young：Old = 1：2となって、Young Generationのサイズは、全体のJava Heapの3分の1になります。-XX：NewSize = OS / JDK Versionごとに異なりYoung Generationの開始サイズを指定します。 Young Generationの大きさは、NewSizeオプション（開始サイズ）とMaxNewSizeオプション（最大サイズ）によって決定されます。-XX：OnError = NoneFatal Errorが発生した場合（例えば、Native HeapからのOut Of Memory Error）、で指定されたOSのステートメントを実行する。異常なJVM障害現象をより詳細に分析しようとする場合に主に使用されます。
-XX：OnError="pmap％p" - > JVMでFatal Errorが発生した場合Process IDのpmapコマンドを実行します。
-XX：OnOutOfMemoryError= NoneOut Of Memory Errorが発生した場合には、に指定されたOSのステートメントを実行します。JDK1.6に追加されたオプションで、Out Of Memory ErrorがJavaでどのよう普遍的に発生するかを知ることができます。
-XX：OnOutOfMemoryError="pmap％p" - > JVMでFatal Errorが発生した場合Process IDのpmapコマンドを実行します。
-XX：ParallelGCThreads = CPUの数Parallel Collectorを使用する場合、GC処理を実行するThreadの数を指定します。デフォルトでは、CPUの数となります。つまり、Parallel GC処理を実行するために、システム全体のCPUを最大限に活用します。一つのMachineに複数のJVMを駆動する環境や、一つのMachineをいくつかの種類のApplicationが共有して使用する環境では、このオプションの値を低く設定してGC Threadの数を減らすことによって、パフォーマンスの向上を図ることができます。Context Switchingによるパフォーマンスの低下を防ぐことができるからなのです。-XX：PermSize = Permanent Generationの最初のサイズを指定します。Permanent Generationの最大サイズは、MaxPermSizeオプションによって指定されます。多くのClassをロードするApplicationは、大きなサイズのPermanent Generationを必要とし、Permanent Generationの大きさが小さくてClassをロードする場合Out Of Memory Errorが発生します。-XX：PretenureSizeThreshold = 0、一般的にObjectはYoung Generationに最初の保存された後、時間の経過に応じてTenured GenerationでPromotionされます。しかし、Objectの大きさがYoung Generationよりも大きい場合、JVMはOld GenerationにObjectを直接保存することもあります。PretenuredSizeThresholdオプションを使用すると、Young Generationを経由せずに直接Old Generationに保存することができます。仮にこのオプションの値が1048576（1M）であれば、1Mサイズ以上のオブジェクトは、Old Generationに直接保存されます。
大きいサイズのオブジェクトをOld Generationに直接保存することにより、不必要なMinor GCを削減する目的で使用されます。
-XX：+ PrintGCApplicationStoppedTimeFalseApplicationでStopが発生した場合に使われる時間情報を記録します。この時間は、GCの作業自体によるStopだけでなく、JVMの内部的な理由でApplication ThreadをStopさせた場合を含見ます。-XX：+ PrintGCDetailsFalseGC発生時Heap領域の比較的詳細な情報をさらに記録します。詳細については、{GC前後のYoung/ Old Generationの大きさ、GC前後のPermanent Generationの大きさ、GC作業にかかった時間}などです。Minor GCが発生した場合PrintGCDetailsオプションの適用例は、以下の通りです。
【GC[DefNew：64575K->959K（64576K）、0.0457646 secs]196016K->133633K（261184K）、0.0459067 secs] 上記のログが意味するところは、以下の通りです。 ・GC前のYoung Generation Usage=64M、Young Generation Size=64M ・GC前ののTotal Heap Usage=196M、Total Heap Size=260M ・GC後のYoung Generation Usage=9.5M ・GC後のTotal Heap Usage=133M ・Minor GC所要時間=0.0457646秒
Major GCが発生した場合PrintGCDetailsオプションの適用例は、以下の通りです。
111.042: [GC 111.042: [DefNew: 8128K->8128K(8128K), 0.0000505 secs] 111.042: [Tenured: 18154K->2311K(24576K), 0.1290354 secs] 26282K->2311K(32704K), 0.1293306 secs] 上記のログは、Minor GC情報のほか、次のようなMajor GC情報を提供します。 GC前Tenured Generation Usage=18M、Tenured Generation Size=24M GC後のTenured Generation Usage=2.3M Major GC所要時間=0.12秒
（参考）PrintGCDetails+ PrintGCTimeStampsオプションの組み合わせが最も一般的に使用されます。
-XX：+ PrintGCTimeStampsFalseGCが発生した時間をJVMの初期駆動時間あたりの記録です。
（参考）PrintGCDetails+ PrintGCTimeStampsオプションの組み合わせが最も一般的に使用されます。
-XX：+ PrintHeapAtGCFasleGC発生前後のHeapの情報を詳細に記録します。PrintHeapAtGCオプションとPrintGCDetailsオプションを一緒に使用すると、GCによるHeap変化の様相を非常に正確に把握することができます。以下にPrintHeapAtGCオプションの適用例を示します。
0.548403: [GC {Heap before GC invocations=1:
Heap
par new generation total 18432K, used 12826K [0xf2800000, 0xf4000000, 0xf4000000]
eden space 12288K, 99% used [0xf2800000, 0xf33ff840, 0xf3400000]
from space 6144K, 8% used [0xf3a00000, 0xf3a87360, 0xf4000000]
to space 6144K, 0% used [0xf3400000, 0xf3400000, 0xf3a00000]
concurrent mark-sweep generation total 40960K, used 195K[0xf4000000, 0xf6800000, 0xf6800000]
CompactibleFreeListSpace space 40960K, 0% used [0xf4000000, 0xf6800000]
concurrent-mark-sweep perm gen total 4096K, used 1158K [0xf6800000, 0xf6c00000, 0xfa800000]
CompactibleFreeListSpace space 4096K, 28% used [0xf6800000, 0xf6c00000]
0.549364: [ParNew: 12826K->1086K(18432K), 0.02798039 secs] 13022K->1282K(59392K)
Heap after GC invocations=2:
Heap
par new generation total 18432K, used 1086K [0xf2800000, 0xf4000000, 0xf4000000]
eden space 12288K, 0% used [0xf2800000, 0xf2800000, 0xf3400000]
from space 6144K, 17% used [0xf3400000, 0xf350fbc0, 0xf3a00000]
to space 6144K, 0% used [0xf3a00000, 0xf3a00000, 0xf4000000]
concurrent mark-sweep generation total 40960K, used 195K [0xf4000000, 0xf6800000, 0xf6800000]
CompactibleFreeListSpace space 40960K, 0% used [0xf4000000, 0xf6800000]
concurrent-mark-sweep perm gen total 4096K, used 1158K [0xf6800000, 0xf6c00000, 0xfa800000]
CompactibleFreeListSpace space 4096K, 28% used [0xf6800000, 0xf6c00000]
} , 0.0297669 secs]
-XX：SoftRefLRUPolicyMSPerMB = 1000（ms）Soft ReferenceがJava Heapからの周期を設定します。デフォルト値は1000ms（1秒）です。 JDK 1.3.1までSoft Referenceは、GCの操作発生時は常にメモリから解放されました。しかし、それ以降のバージョンでは、Free Memoryに比例して一定時間程度のメモリに保持時間が変更された。仮にこの値が1000（1秒）であれば、HeapのFree Memory 1Mごとに直前に参照された時間で1秒過ぎていない場合、メモリから解放しない事になります。
この値に大きく付与するSoft Referenceが長くメモリに留まって使用効率を高くします。一方、メモリ占有率は高くなります。したがってApplicaitonでSoft Referenceを多く使用し、Free Memoryが多くない状況では、この値を下げる必要があります。一方、Soft Referenceに基づいてCacheを実装して、Free Memoryに余裕がある状況では、この値を高めることで性能向上を図ることができます。
-XX：SurvivorRatio = 5〜6（OS / Versionごとに異なります）Survivor SpaceとEden Spaceの割合を指定します。もしこの値が6であれば、To Survivor Ratio：From Survivor Ratio：Eden Space = 1：1：6となります。つまり、1つのSurvivor SpaceのサイズがYoung Generationの1/8になります。Survivor Spaceのサイズが大きいTenured Generationに移しか前の中間バッファ領域が大きくなります。したがってFull GCの頻度を減らす役割をすることができます。一方、Eden Spaceのサイズが減るのでMinor GCが頻繁に発生するようになります。-XX：+ TraceClassLoadingFalseClass Loadingを追跡するメッセージを記録するかどうかを指定します。TraceClassUnloadingオプションと一緒にClassLoaderの問題を追跡しようとするときに使用されます。-XX：+ TraceClassUnloadingFalseClass Unloadingを追跡するメッセージを記録するかどうかを指定します。TraceClassLoadingオプションと一緒にClassLoaderの問題を追跡しようとしたときに使用されます。このオプションは、JDK 1.6で追加されました。-XX：+ UseAdaptiveSizePolciyTrueParallel Collectorを使用した場合Young GenerationのサイズをAdaptiveに適用するかどうかを指定します。 Parallel Collectorの目的は、Throughputを最大化するものであり、この目的に応じてYoung GenerationのサイズをJVM自身調整します。
（注意）Adaptive Sizeを使用している場合、Young Generationのサイズが誤って計算されてFull GCを過剰誘発するような誤動作をする場合があります。この場合には、このオプションの値をFalse（-XX：-UseAdaptiveSizePolicy）に変更します。
-XX：+ UseCMSCompactAtFullCollectionTrueCMS CollectorによるConcurrent GC実行時Compactionタスクを実行するかどうかを指定します。この値がTrueの場合、Old GenerationのFragmentationによりPromotion Failureが発生したときStop The World方式のFull GCを実行しCompactionが行われます。JDK 1.4.2からTrueがDefault値です。より詳しくは、CMSFullGCsBeforeCompactionパラメータを参照してください。-XX：+ UseCMSInitiatingOccupancyOnlyFalseConcurrent Full GCを実行する基準として、最初に指定された割合を固定的に使用するかどうかを指定します。最初の割合は、CMSInitiatingOccupancyFractionオプションによって指定されます。
CMS Collectorを使用している環境では、Full GCが頻繁に発生する場合CMSInitiatingOccupancyFractionオプションの値を低く（50未満）で指定し、このオプションの値をTrueに設定する方法を多く使用します。
-XX：+ UseConcMarkSweepGCFalseCMS Collectorを使用かどうかを指定します。GC Pauseによるユーザーの応答時間の低下現象を軽減たい場合に使用することをお勧めします。-XX：+ UseParallelGC環境に応じてParallel Collectorを使用かどうかを指定します。JDK 1.4まではFalseがデフォルトです。 JDK 1.5からサーバークラスのマシンである場合には、True、クライアント級マシンの場合にはFalseがデフォルトです。サーバークラスのマシンとは、CPUが2個以上、Physical RAMが2G以上のマシンを意味します。大きいサイズのYoung Generationが、一般的なエンタープライズ環境では、Parallel Collectorを使用することにより、Minor GCによるGC Pauseを最小限に抑えることができます。 Parallel CollectorはYoung Generationでのみ動作するという事実に注意しましょう。 Old GenerationのParallel Collectionを使用しようとする場合には、UseParallelOldGCオプションを使用します。-XX：+ UseParallelOldGCFalseOld GenerationのParallel Collectionを実行するかどうかを指定します。JDK 1.6で追加されたオプションです。-XX：+ UseParNewGC環境に応じてCMS Collectorを使用している場合に限って、Young Generationに対してParallel Collectionを実行するかどうかを指定します。このオプションとUseParallelGC、UseParallelOldGCオプションとの違いを明確に区分しなければなりません。-XX：+ UseSerialGC環境に応じてSerial Collectorを使用かどうかを指定します。JDK 1.4まではDefaultの値がTrueです。JDK 1.5ではUseParallelGCオプションで説明したようマシンの評価に基づいてDefault値が決定されます。
IBM JVM（1.5基準）
Sun Hotspot JVMではCommand LineでJVM Optionを指定する必要がありますが、IBM JVMは、次のような3つの方法でOptionを指定することができます。
・Command Line：java-Xgcpolicy：optthruputのような形で指定します。 ・Options File：-Xoptionsfileオプションを利用してOptionを集めたText Fileを指定します。 Optionsfileは、次のような形態です。 #My options file -X -X=\、\ -D= ・IBM_JAVA_OPTIONS環境変数：IBM_JAVA_OPTIONS環境変数に値を指定します。（例えば、IBM_JAVA_OPTIONS=-X-X=）
Standard Options
| Option | Description |
| -memorycheck: | JVM内部で発生するMemory Leakを追跡するための用途に使用されます。JVM自体は、C/ C ++で実装されました。次のようなオプションが提供されています（IBM JVM Diagnositics Guideからの抜粋） |
・all – The default if just -memorycheck is used. Enables checking of all allocated and freed blocks on every free and allocate call. This check of the heap is the most thorough and should cause the JVM to exit on nearly all memory-related problems very soon after they are caused. This option has the greatest impact on performance.
・quick – Enables block padding only. Used to detect basic heap corruption. Pads every allocated block with sentinel bytes, which are verified on every allocate and free. Block padding is faster than the default of checking every block, but is not as effective.
・nofree – Keeps a list of already used blocks instead of freeing memory. This list is checked, along with currently allocated blocks, for memory corruption on every allocation and deallocation. Use this option to detect a dangling pointer (a pointer that is “dereferenced” after its target memory is freed). This option cannot be reliably used with long-running applications (such as WAS), because “freed” memory is never reused or released by the JVM.
・failat= – Causes memory allocation to fail (return NULL) after . Setting to 13 will cause the 14th allocation to return NULL. Deallocations are not counted. Use this option to ensure that JVM code reliably handles allocation failures. This option is useful for checking allocation site behavior rather than setting a specific allocation limit.
・skipto= – Causes the program to check only on allocations that occur after . Deallocations are not counted. Used to speed up JVM startup when early allocations are not causing the memory problem. As a rough estimate, the JVM performs 250+ allocations during startup.
・callsite= – Prints callsite information every . Deallocations are not counted. Callsite information is presented in a table with separate information for each callsite. Statistics include the number and size of allocation and free requests since the last report, and the number of the allocation request responsible for the largest allocation from each site. Callsites are presented as sourcefile:linenumber for C code and assembly function name for assembler code. Callsites that do not provide callsite information are accumulated into an “unknown” entry.
・zero – Newly allocated blocks are set 0 instead of being filled with the 0xE7E7xxxxxxxxE7E7 pattern. Setting to 0 helps you to determine whether a callsite is expecting zeroed memory (in which case the allocation request should be followed by memset(pointer, 0, size)).
-showversionJavaのバージョンと基本的な使い方についての情報を提供します。-verbose：Optionに基づいて詳細情報を出力します。次のようなオプションが提供されます。
・class – Class Loading情報をStandard Errに出力します。出力例は以下の通りです。
class load: java/io/FilePermission class load: java/io/FilePermissionCollection class load: java/security/AllPermission ... class load: test class load: test from: file:/C:/Documents/Java_Test/GC%20dump/
・dynload – Class Loadingの非常に詳細な情報を提供します。クラス名、クラスサイズ、ロード時間などの情報を含んでいます。出力例は以下の通りです。
< Class size 6594; ROM size 7056; debug size 0> < Read time 128 usec; Load time 126 usec; Translate time 222 usec> < Class size 4143; ROM size 3264; debug size 0> < Read time 103 usec; Load time 81 usec; Translate time 117 usec> < Class size 239; ROM size 248; debug size 0> < Read time 44 usec; Load time 23 usec; Translate time 20 usec> < Class size 370; ROM size 448; debug size 0> < Read time 0 usec; Load time 28 usec; Translate time 39 usec>
・gc – GCの操作に関する情報を提供すします。詳細については、GC Dumpを参照します。
・jni – JNI呼び出しに関する情報を提供します。出力例は以下の通りです。
([B)V>
・sizes – Memoryの使用に関する設定値を出力します。出力例は以下の通りです。
-Xmca32K RAM class segment increment -Xmco128K ROM class segment increment -Xmns0K initial new space size -Xmnx0K maximum new space size -Xms4M initial memory size -Xmos4M initial old space size -Xmox1047608K maximum old space size -Xmx1047608K memory maximum -Xmr16K remembered set size -Xmso32K OS thread stack size -Xiss2K java thread stack initial size -Xssi16K java thread stack increment -Xss256K java thread stack maximum size -Xscmx16M shared class cache size
・stacks – Thread別Java/C Stackの使用サイズを出力します。出力例は以下の通りです。
JVMVERB000I Verbose stack: “Thread-1” used 188/3756 bytes on Java/C stacks
JVMVERB000I Verbose stack: “Thread-2” used 516/3756 bytes on Java/C stacks
JVMVERB000I Verbose stack: “main” used 1368/0 bytes on Java/C stacks
JVMVERB000I Verbose stack: “Finalizer thread” used 456/2308 bytes on Java/C stacks
JVMVERB000I Verbose stack: “Gc Slave Thread” used 232/3060 bytes on Java/C stacks
Non-Standard Options
| Option | Default | Description |
| -Xalwaysclassgc | -Xclassgcオプションによって決定 | lobal Collectionが発生したときClass GCを実行するかどうかを指定します。classgcオプションと同じ値であり、DefaultはTrueです。 |
| -Xbootclasspath | Sun JVMのbootclasspathオプションと同じ | |
| -Xcheck:jni | False | Sun JVMのcheck：jniオプションと同じ |
| -Xclassgc | True | Classloaderが変わった場合にのみ、Class GCを実行するかどうかを決定 |
| -Xcodecache | OS/ Hardware Architectureに基づいて決定 | |
| -Xcomp | -Xjit：count=0オプションを使用したものと同じです。z/ OSでのみ使用され、deprecatedオプションです。 | |
| -Xcompactexplicitgc | False | System.gc（）の呼び出しによるExplicit GCが発生した場合、常にCompactionを実行するかどうかを決定します。Sun Hotspot JVMの場合には、System.gc（）の呼び出しが発生した場合、必ずFull GCを実行します。一方、IBM JVMの場合には、前のGC処理でCompactionが発生していない場合にのみ、Compactionを実行します。 |
| -Xcompactgc | False | System GCやGlobal GCが発生するたびにCompactionを実行します。 |
| -Xconcurrentbackground | 1 | Response Time CollectorでConcurrent Markを実行するBackground Threadの数を指定します。Concurrent Background ThreadはApplication Threadの性能を多少低下させることができるので、一つだけ駆動することが望ましい。ただし、Concurrent Mark処理がうまく進まず、問題が生じる場合には、この値を育てることが解決策になることができます。 |
| -Xconcurrentlevel | ||
| -Xconmeter | ||
| -Xdisableexcessivegc | False | GCの操作に過度に多く（Excessive）時間がかかった場合にOut Of Memory Errorを誘発しないように指定します。 |
| -Xdisableexplicitgc | False | System.gc（）の呼び出しによるGC作業を無効にします。このオプションを使用すると、System.gc（）を呼び出しても、GCの操作が発生しません。RMIによる不要なGCの操作やユーザーのミスによる強制的なGCの操作を防止しようとする目的のために使用されます。 |
| -Xdisablejavadump | False | Java Dumpの生成を無効にします。IBM JVMは、致命的なErrorやSignalを受信すると、Java Dumpを生成することにより、事後の問題をデバッグすることができます。特定の問題のために過度に多くのDumpが生成されるときに、このオプションを無効にさせる場合があります。 |
| -Xdisablestringconstantgc | False | Interned StringのGC処理を無効にします。 |
| -Xenableexcessivegc | True | GCの操作に過度に多く（Excessive）時間がかかった場合にOut Of Memory Errorを誘発するように指定します。disableexcessivegcと反対の役割となります。 |
| Xenablestringconstantgc | True | Interned StringのGC処理を有効にします。disablestringconstantgcオプションと反対の役割となります。 |
| -Xgcpolicy | optthruput | Garbage Collectorの種類を決定します。 |
・optthruput：Throughput Collectorを使用します。スループット（Throughput）を最適化する目的で使用され、Default Collectorです。
・optavgpause：Response Time Collectorを使用します。応答時間（Response Time）を最適化する目的で使用されます。GCによるPause Timeを最小するためにConcurrent Mark/ Sweepのタスクを実行します。Throughput Collectorに比べてスループットに多少（5〜10％）低下します。
・gencon：Concurrent Generational Collectorを使用します。IBM JDK1.5で追加された。Sun Hotspot JVMのCMS Collectorとほぼ同じように動作します。
・subpool：Subpool Collectorを使用します。
-XgcthreadsCPU＃Throughput CollectorはMark＆Sweep作業をParallelに、すなわち、同時に複数のThreadを使用して実行します。このオプションを使用してParallel GCを実行するThreadの数を指定します。基本的にはCPUの数をすべて活用します。もし一つのMachineで複数のJVMを駆動したり、他の種類のApplicationとJVMが共存する場合には、この値を減らすことにより、Context Switchingによるパフォーマンスの低下を避けることができます.gcworkpackets int iss-Xjit：True（JITコンパイルを使用すること）JITコンパイルオプションを決定します。指定しない場合、単純にJITコンパイルを有効にします。このオプションは、JITコンパイラのバグが原因でJVMの障害についてWorkaroundに多く活用されます。
JITコンパイラのバグによるJVM Crashが発生した場合には、次のようなタイプのError Stacktraceが記録される。
... TR_GlobalRegisterAllocator::perform() TR_OptimizerImpl::performOptimization() TR_OptimizerImpl::performOptimization() TR_OptimizerImpl::optimize() ...
この場合には、次のようなオプションを利用してJITコンパイルを制御することができます。
＃Inliningを無効にします。
-Xjit：disableInlining
-Xjit：{java/ lang/ Math.max（II）I}（disableInlining）
＃特定のメソッドをOptimizationから除外します。
-Xjit：exclude={java/ lang/ Math.max（II）I}...
次のオプションは、JITコンパイラの問題が発生した場合、これを追跡しようとするときに使用されます。
count=番目実行でMethodをJITコンパイルにします。JITの問題を追跡する場合は、 「0」の値を使用することにより、より早くコンパイルが行われるようになります。 optlevel=[noOpt|cold|warm|hot|veryHot|scorching] 【非最適化〜最高最適化までJITコンパイルによる最適化のレベルを指摘します。 verbose JITコンパイルの過程で使用された情報と、コンパイルプロセスを出力します。
以下に-Xjit：verboseオプションの出力例を示します。countの値は1000、optlevel値はwarmがデフォルトであることを知ることができます。
JIT type: Testarossa (Full)
JIT options specified:
verbose
options in effect:
bcount=250
catchSamplingSizeThreshold=1100
classLoadPhaseInterval=500
classLoadPhaseThreshold=155
code=512 (KB)
codepad=0 (KB)
codetotal=0 (KB)
count=1000
...
stack=256
target=ia32-win32
verbose=1
+ (warm) java/lang/Double.doubleToRawLongBits(D)J @ 0x41630014-0x41630030
+ (warm) java/lang/System.getEncoding(I)Ljava/lang/String; @ 0x41630054-0x41630145
+ (warm) java/lang/String.hashCode()I @ 0x4163017C-0x4163024A
+ (warm) java/util/HashMap.put(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
@ 0x4163027C-0x416304AF
+ (warm) java/util/Locale.toLowerCase(Ljava/lang/String;)Ljava/lang/String;
@ 0x416304DC-0x416307FF
...
+ (warm) java/io/FileOutputStream.writeBytes([BIILjava/io/FileDescriptor;)V @ 0x41636C34-0x41636D45|-
loainitial loamaximum loaminimum lp maxe maxf maxt mca mco mine minf mint mn mns mnx mo moi mos mox mr mrx ms mso mx noaot noclassgc nocompactexplicitgc nocompactgc-XnojitFalseJITコンパイルオプションを使用しません。noloa nopartialcompactgc nosigcatch nosigchain optionsfile oss partialcompactgc quickstart realtime rs runhprof samplingExpirationTime scmxshareclasses sigcatch sigchain softrefthreshold ss ssi thr verbosegclog：
外部参照
