Garbage Collector

　

“パフォーマンス”を向上させるさせるということは、次の2つのことを意味します。

　

・Throughput改善：どのように多くの量の仕事を処理することができるかが性能改善の基準となるパターン。
・Response Time改善：ジョブの処理要求に対してどのよう応答を速くするかが性能改善の基準となるパターン。

　

JVMが提供するGarbage Collectorも、上記の二つの基準を使用します。つまり、特定のGarbage Collectorは、Throughputの最大化を目的に、別のGarbage Collectorは、Response Timeの最適化を目的として機能するのです。ThroughputとResponse Timeの二つの目的は、相互背反的な性格を持っています。したがってApplicationの要件に応じて最適のGarbage Collectorを選択する必要があります。

　

　

Sun HotSpot JVMは、Generationに基づいてHeap構造を使用します。GeneationベースのHeap構造は、HeapをYoung Generationが存在するNew SpaceとTenured Generationが存在するOld Spaceに分けて管理します。

　

Sun HotSpot JVM系では、次のような種類のGarbage Collectorを提供します。

　

　

JDK1.4までの基本的な（Default）Collectorあります。1.5から基本CollectorにどのCollectorを使用するかをJVMが決定します。CPUが2つ以上、メモリが2G以上の「サーバー」級マシンではParallel Collectorが選択され、「クライアント」級マシンではSerial Collectorが選択されます。UseSerialGCオプションを利用して強制的に指定することができます。

　

　

Young GenerationのMinor GC処理を並列に処理することにより、GCの性能を高めます。UseParallelGCオプションによって活性化されます。Throughput、すなわちスループットを最大化する目的があります。
JDK1.5からServer級マシンの場合は、Parallel CollectorがDefault Collectorです。Server級マシンとは、2つ以上のCPU、2G以上のPhysical Memoryを備えたマシンを意味します。

　

　

Old GenerationのGC処理をApplication Threadと同時に（Concurrent）進行します。UseConcMarkSweepGCオプションによって活性化されます。Concurrent GC作業はGC Pause時間を減らすことによって、Response Timeを改善させますが、Throughputはやや減少することができます。
CMS CollectorのConcurrent GC作業はOld GenerationのGC処理にのみ影響を与えます。

　

　

IBM JVMは、Sun HotSpot JVMとは異なり、GenerationベースのHeap構造を使用していません。つまり、Single SpaceからなるHeap構造を使用するのです。ただし、JDK1.5以降では、Sun HotSpot JVMと同じ方法のGeneration Heap構造を付加的に支援します。

　

IBM JVM系では、次のような種類のGarbage Collectorを提供します。

　

　

基本は（Default）Collectorです。 Throughputを最適化するように動作します。 gcpolicy（-Xgcpolicy：optthruput）オプションによって活性化されます。
IBM JVMは、基本的にGenerationを使用していません。したがってYoung GenerationとOld Generationの区分がなく、Minor GCとMajor GCの区分もありません。ただし、JDK 1.5で導入されたConcurrent Generational Collectorを使用すると、Sun Hotspot JVMと同じ方法、すなわちGenerationに基づいたHeap管理手法を使用します。

　

Throughput CollectorによるHeap管理手法をまとめてみると次の通りです。

　

・Young GenerationとOld Generationの区分がなく、一つのHeap領域に管理されます。
・一般的なGCの操作は、基本的にMark and Sweep作業だけを実行します。すなわち、Compaction作業は行ないません。
・Mark and Sweepだけでメモリを確保できない場合には、Compaction作業が行われます。 
　Compaction作業はSun Hotspot JVMでのFull GCと同じ方式です。
　つまり、すべてのApplication ThreadをStopしCompactionを実行します。

　

　

Throughput Collectorとは異なり、応答時間を最適化するように動作します。gcpolicy（-Xgcpolicy：optavgpause）オプションによって活性化されます。

　

Response Time CollectorによるHeap管理手法を整理すると、次の通りです。

　

・Young GenerationとOld Generationの区別なく一つのHeap領域に管理されます。
・Concurrent Mark処理とConcurrent Sweep作業がさらに発生します。
　つまり、Concurrent Mark - > Mark＆Sweep（STW） - > Concurrent Sweepの段階でGCが発生し、
　これにより、Mark and SweepによるApplication Stop時間を最小限に抑えることができます。
　ただし、それほどThroughputは減少します。
・Compaction作業はThroughput Collectorと同じように動作します。

　

IBM JVMのResponse Time CollectorはSun Hotspot JVMのCMS Collectorと非常に似ています。各JVMベンダーがお互いの長所を吸収することで生じる自然な現象だと見ることができます。

　

　

1.5で追加されたCollectorに、Sun HotSpot JVMのような方式、すなわちGenerationに基づいHeap管理手法を提供します。Sun Hotspot JVMのCMS Collectorと動作がほぼ同じです。gencon（-Xgcpolicy：gencon）オプションによって活性化されます。

　

　

Java Heapを複数のSub Poolに分けて管理する手法を使用します。16 CPU以上のサーバー環境でのみ使用することを推奨します。subpool（-Xgcpolicy：subpool）オプションによって活性化されます。

　

　

BEA JRockit JVM系でのGarbage Collector分類方法は、他のJVMよりも少し複雑です。JRockit JVMでは、「GCの優先順位」と「GCモード」の組み合わせに基づいてGarbage Collectorを区分します。

　

　

Throughputを最適化するように動作します。-Xgcprio：throughputオプションによって活性化されます。初期起動時にはSingle-spaced Parallel GCモードで動作しますが、実行時にGCモードが変更することができます。

　

Pause Timeを最適化するように動作します。-Xgcprio：pausetimeオプションによって活性化されます。初期起動時にはSingle-spaced Concurrent GCモードで動作しますが、実行時にGCモードが変更することができる。

　

　

HeapをSingle Spaceで管理しParallelにGC処理を実行する。IBM JVMのThroughput Collectorとほぼ同じ方式である。-Xgc：singleconオプションによって活性化される。

　

HeapをSingle Spaceで管理しConcurrentにGC処理を実行する。IBM JVMのResponse Time Collectorとほぼ同じ方式である。-Xgc：parallelオプションによって活性化される。

　

Generationに基づいてHeapを管理する。IBM JVMのGenerational Concurrent Collectorとほぼ同じ方式である。-Xgc：genconオプションによって活性化される。

　

　

HP-UXのHotSpot JVMは、Sun HotSpot JVMとほぼ同じ機能を提供する。

　

　

1.Sun HotSpot JVMのHeap管理手法
2.IBM JVMのHeap管理手法

　

1.Sun JDK 6.0 Troubleshooting Guide

2.Sun JDK 5.0 Troubleshooting Guide

3.IBM JDK 5.0 Diagnostics Guide