FJVMでサポートされるガーベジコレクション(GC)処理には、JavaヒープのNew世代領域に対するGC制御方法の違いにより、以下の4種類があります。
なお、JDK/JREのバージョン、実行モード、Java VMの種類により、サポートされるGCの種類が異なります。また、Java VMの種類により、デフォルトで動作するGCが異なります。
“表8.2 サポートされるGCの種類”に、サポートされるGCの種類とデフォルトのGCを示します。
JDK/JREのバージョン | JDK/JRE 5.0 | JDK/JRE 6 | |||||
|---|---|---|---|---|---|---|---|
JDK/JREの実行モード | 32ビットモード | 64ビットモード | 32ビットモード | 64ビットモード | |||
Java VMの種類 | Client VM | FJVM | FJVM ※ | Client VM | FJVM | FJVM ※ | |
シリアルGC | ◎ | ○ | ○ | ◎ | ○ | ○ | |
FJGC | ○ | ||||||
パラレルGC | ○ | ◎ | ◎ | ○ | ◎ | ◎ | |
CMS付きパラレルGC | □ | □ | □ | □ | □ | □ | |
○：サポートされるGC
◎：サポートされるGC、かつデフォルトのGC
□：Interstage Application Server Enterprise EditionでだけサポートされるGC
※実行モードが64ビットモードのClient VMは提供していません。
GCは、デフォルトのGCの使用を推奨します。
通常、デフォルトのGCを変更する必要はありません。
■New世代領域の使われ方
FJGC以外のGC処理におけるNewGC処理では、New世代領域を「eden space」、「from space」および「to space」の3つの内部領域に細分割し、当該領域上において、一般に世代別GC制御と言われる制御方法を用いて、Javaアプリケーションが生成要求したオブジェクトを管理・制御しています。
このうち、「from space」および「to space」は、Java VMがNewGC処理を行う際の作業域的な役割を持つ領域となっています。そのため、「from space」および「to space」の各領域が占める大きさのうち、Javaアプリケーションからのオブジェクト生成要求のために使用される大きさは、その領域の一部分だけとなります。
そのため、FJGC以外のGC処理を使用している場合は、ガーベジコレクションのログ出力などの出力データにおいて、メモリ割り当てプールやNew世代領域に空きがあるように見える場合であっても、実際には空きがない場合があります（空きがあるように見える場合であっても、その差は、NewGC処理用の作業域的な役割で使用済となっている場合があります）。
■ガーベジコレクション処理の実行抑止
“表8.3 ガーベジコレクション処理の実行が抑止される機能”に示す機能を使用するJavaアプリケーションを実行すると、Javaヒープ内に存在する全オブジェクトの移動が禁止されるクリティカルセクションと呼ばれる状態が、当該機能の利用状況に応じて発生します。
クリティカルセクション状態発生時は、オブジェクトの移動が禁止されるため、オブジェクト移動が必須となるGC処理の実行が抑止される状態となります。
Java VMは、JavaアプリケーションによりGC処理の実行が抑止されている際に発生したオブジェクト生成要求に対し、New世代領域に空きが無い場合には、Old世代領域の空き領域を一時的に使用して対応します。
そして、要求されたオブジェクト量を満たす空きがOld世代領域にない場合には、java.lang.OutOfMemoryError例外を発生させます。
そのため“表8.3 ガーベジコレクション処理の実行が抑止される機能”の機能を多用するJavaアプリケーションの場合は、GC処理実行が抑止される状態も多数発生する可能性が高くなり、当該機能を多用しないJavaアプリケーションに比べ、GC処理実行抑止に因るjava.lang.OutOfMemoryError例外が発生しやすい状態にあります。
特にOld世代領域が小さい状態でJavaアプリケーションを実行した場合は、Old世代領域の空きとなり得る最大値（仮にOld世代領域を全く使用しない場合だと、Old世代領域自身の大きさ）もその大きさに比例して小さいため、その傾向が強まることがあります。
なおFJVMでは、GC処理の実行抑止によりjava.lang.OutOfMemoryError例外が発生したかどうかの情報を出力する機能を提供しています。
詳しくは“8.6.1.1 メモリ領域不足事象発生時のメッセージ出力機能の強化”を参照してください。
【GC処理の実行が抑止される状態となるJNI関数】 - GetPrimitiveArrayCritical()実行からReleasePrimitiveArrayCritical()実行までの間 |
【GC処理の実行が抑止される状態となるJVMPI関数】 - DisableGC()実行からEnableGC()実行までの間 |
【GC処理の実行が抑止される状態となるJVMPIイベント】 - JVMPI_EVENT_THREAD_START |
■JVMPIとJVMTI
次の場合、Java Virtual Machine Profiling Interface(JVMPI)をサポートしていません。
JDK/JRE 5.0を使用し、GC処理としてパラレルGCまたはCMS付きパラレルGCが選択されている場合
JDK/JRE 6を使用している場合
JVMPI相当の機能を使用する場合には、JDK/JRE 5.0から導入されたJava Virtual Machine Tool Interface(JVMTI)を使用してください。
JDK/JRE 5.0でJVMPI機能は推奨されていません。やむを得ず使用する場合は、GC処理としてシリアルGCを使用してください。
■RMI処理の分散GC
JavaのRMI処理では、クライアントで不要となった参照に対するサーバ側のオブジェクトを破棄するため、Distributed GC(分散GC)という処理を行います。その処理の一貫として、以下のプロパティで設定された時間間隔(デフォルトの時間間隔は1分)ごとに、java.lang.System.gc()実行によるFull GCが発生します。なお、分散GCとメモリ不足等による通常のガーベジコレクション(GC)が同時に発生した場合は、メモリ不足等による通常のGCが実行され、分散GCによるFullGCは実行されません（メモリ不足等による通常のGCがNewGC処理だった場合は、FullGCにはなりません）。
-Dsun.rmi.dgc.server.gcInterval=時間間隔(ミリ秒) |
分散GCは独自のタイマー制御の元で実行されるため、メモリ不足等による通常のGCの実行とは関係せずに実行されます。そのため、GC処理の結果ログを見た場合、Javaアプリケーションとしての処理がほとんど動作していない時間帯やメモリ不足とは思われない状態のときに、FullGC処理が実行されているように見える場合があります。
またプロパティで指定された時間間隔が短い場合、Interstage Application Serverの予兆監視機能により警告を受ける(EXTP4368メッセージやISJEE_OM3204メッセージが出力される)場合がありますので、注意してください。
