これについては完全にはわかりませんが、すべてのメモリ プール (少なくとも旧世代のもの) を制御するガベージ コレクタが、主要な gc に使用されるものであると想定しています。例: 以下の 2 つのコレクターで JVM を実行しています。
- PSマークスイープ
- MemoryPoolNames: PS Eden Space、PS Survivor Space、PS Old Gen、PS Perm Gen
- コレクション数: 68
- PSスカベンジ
- MemoryPoolNames: PS エデン スペース、PS サバイバー スペース
- コレクション数: 2690
これを考慮すると、PS Scavenge はマイナー GC に使用され、PS MarkSweep はメジャー GC に使用されます。
更新 (@ajeanson のコメントに基づく、フィードバックありがとうございます):
事実上、ここに記載した例は、私が使用していた JVM の MXBean で公開されている情報から取得したものです。あなたが言及したように、これらは GC アルゴリズムであり、GC の MXBean が使用している名前は、GC が使用しているアルゴリズムに基づいています。これについてさらに情報を探していました。この記事http://download.oracle.com/javase/6/docs/technotes/guides/management/jconsole.htmlには、次のように書かれています。
Java HotSpot VM は、若い世代 (「ナーサリ」と呼ばれることもある) と古い世代の 2 つの世代を定義します。若い世代は「エデン空間」と2つの「サバイバー空間」で構成されています。VM は最初にすべてのオブジェクトを Eden 空間に割り当て、ほとんどのオブジェクトはそこで消滅します。マイナー GC を実行すると、VM は残りのオブジェクトを Eden スペースから Survivor スペースの 1 つに移動します。VM は、サバイバー スペースに十分長く存在するオブジェクトを古い世代の「tenured」スペースに移動します。Tenured ジェネレーションがいっぱいになると、フル GC が発生します。フル GC は、すべてのライブ オブジェクトを含むため、多くの場合非常に遅くなります。パーマネント ジェネレーションは、クラスやメソッド オブジェクトなど、仮想マシン自体の反映データをすべて保持します。
MXBeans の collectionCount プロパティを見ると、"PS MarkSweep" コレクター (Old Generation プールを管理するコレクター) の場合、詳細出力で完全な GC を取得した場合にのみコレクション数が増加するようです。私が間違っている可能性があり、場合によっては、このコレクターがマイナー GC も実行する可能性がありますが、これについて完全に確認するには、さらにテストを実行する必要があります。誰かが何か他のことを見つけた場合、またはこの問題についてより具体的な情報をお持ちの場合はお知らせください。私は非常に興味があります。