ガーベジコレクション制御としてCMS付きパラレルGCを使用する場合は、以下の点に注意してください。
CMS付きパラレルGCが使用できるエディション
CMS付きパラレルGCによるGC制御は、以下のエディションに搭載されたJDK/JRE 5.0、6にだけ提供しています。
Interstage Application Server Enterprise Edition
アプリケーション性能低下の可能性
CMS付きパラレルGCを使用した場合に動作するCMS-GC(コンカレント・マーク・スイープGC)は、Javaアプリケーションと同時並列に動作するため、CMS-GC動作分のCPU資源がJavaアプリケーションへ渡りません。そのため、パラレルGCを使用した場合と比較し、Javaアプリケーションにおけるスループット性能/応答性能は低下する可能性があります。ただし、性能低下の度合いは、実行するJavaアプリケーションの処理内容/実行環境により大小様々です。
性能差は、Javaヒープサイズのチューニングにより緩和/解決できる可能性があります。
Javaヒープ必要量拡大の可能性
CMS付きパラレルGCを使用した場合に動作するCMS-GCにより、Old世代領域内の空き領域の断片化(フラグメンテーション)が発生します。そのため、パラレルGCやシリアルGC/FJGCを使用した場合よりも、Javaヒープサイズを大きくすることが必要な場合があります（パラレルGCやシリアルGC/FJGCを使用した際のJavaヒープサイズよりも、10%～20%程度大きくすることが必要となる場合があります）。
New世代領域用GCの性能差の可能性
New世代領域用GCの処理時間が、CMS付きパラレルGCを使用した場合とパラレルGCを使用した場合とでは異なる可能性があります。その時間差により、必要とされる性能がパラレルGCでしか得られない場合は、CMS付きパラレルGCではなく、パラレルGCを使用してください。
New世代領域サイズに関するチューニングの必要性
CMS付きパラレルGCにはNew世代領域およびOld世代領域の大きさを、Javaアプリケーションの実行状況によって自動的に調整する機能がありません。そのためチューニング時の観点として、Javaヒープサイズ(メモリ割り当てプールの大きさとPermanent世代領域の大きさ)の他に、New世代領域の大きさに関するチューニングも必要となります。またJavaプロセスが多重に走行する場合の観点でのチューニング（システム負荷要因による変動の考慮）も必要となる可能性があります。
getCollectionTime()メソッドと-verbose:gc出力の結果不一致の可能性
CMS-GCが動作している最中にJavaヒープ不足やjava.lang.System.gc()実行などによりFull GC要求が発生した場合、Full GC処理は、実行中のCMS-GC処理の終了を待ってから開始されます。その際、CMS-GCが処理しているデータの整合性を維持させるため、CMS-GC処理の終了は強制的な打ち切り終了ではなく、CMS-GC内で打ち切り可能な処理まで完了させてからの終了になります。そのため、Full GC処理要求の発生から実際にFull GC処理が開始されるまでに、ある程度の時間差が生じる可能性があります。
CMS付きパラレルGCを使用しているJava VMに対するjava.lang.management.GarbageCollectorMXBeanクラスのgetCollectionTime()メソッドの戻り値(ガーベジコレクション処理の累積経過時間)には、Full GC処理要求の発生から実際にFull GC処理が開始されるまでの時間差も含まれます。そのため、純粋にFull GC処理としてのGC処理実行時間を出力している“-verbose:gc”オプション指定時のガーベジコレクション処理の結果ログ情報(Full GCに対するGC処理実行時間)を累積しても、それらの値が一致しない可能性があります。
JDK/JRE 5.0のJVMTI
JDK/JRE 5.0を使用し、GC処理としてCMS付きパラレルGCが選択されている場合、Java Virtual Machine Tool Interface(JVMTI)で、以下の権限を必要とする機能は使用できません。
can_tag_objects
can_generate_object_free_events
