Java HotSpot Garbage Collectionを翻訳しました。
第１章 The Garbage-First Garbage Collector
The Garbage-First Garbage Collector (or G1 GC for short) is a new GC that is being introduced in the Java HotSpot VM in JDK 7. An experimental version of G1 has also been released in Java SE 6 Update 14. G1 is the long-term replacement for HotSpot's low-latency Concurrent Mark-Sweep GC (widely referred to as CMS).
Garbage-First Garbage Collector (短縮名：G1 GC)は、JDK 7のJava HotSpot VMで導入される新しいGCです。実験バージョンのG1は、Java SE 6 Update 14でもリリースされました。G1は、HotSpotの低レイテンシ性のConcurrent Mark-Sweep GC（広くCMSと呼ばれている）に、長期的に置き換わるものです。
1.1. Attributes （属性）
G1 is a “server-style” GC and has the following attributes.
G1はサーバ向けGCで、次の属性を持ちます。
Parallelism and Concurrency. G1 takes advantage of the parallelism that exists in hardware today. It uses all available CPUs (cores, hardware threads, etc.) to speed up its “stop-the-world” pauses when an application's Java threads are stopped to enable GC. It also works concurrently with running Java threads to minimize whole-heap operations during stop-the-world pauses.
並行と並列性：G1は最新のハードウェアに搭載されている並行性を利用します。G1はすべての利用可能なCPU(コアやハードウェア・スレッドなど)を使用し、GC実行時にアプリケーションのJavaスレッドがすべて停止される「stop-the-world」を短縮化します。G1は、stop-the-world中の全ヒープに対する操作を最小限にするために、複数のJavaスレッド上で並列に動作します。
Generational. Like the other HotSpot GC's, G1 is generational, meaning it treats newly-allocated (aka young) objects and objects that have lived for some time (aka old) differently. It concentrates garbage collection activity on young objects, as they are the ones most likely to be reclaimable, while visiting old objects infrequently. For most Java applications, generational garbage collection has major efficiency advantages over alternative schemes.
世代：他のHotSpot GCのように、G1も世代別に動作します。新しく割り当てられたばかりの若いオブジェクトと、生存期間の長い古いオブジェクトを別々に扱います。G1は、まれに古いオブジェクトを監視すると同時に、若いオブジェクトに対するガーベジコレクション活動に集中します。なぜなら、若いオブジェクトのほとんどが回収されるからです。
世代別ガーベジコレクションは、ほとんどのJavaアプリケーションにおいては、他の方法に勝る大きな効果をもたらします。
Compaction. Unlike CMS, G1 performs heap compaction over time. Compaction eliminates potential fragmentation problems to ensure smooth and consistent long-running operation.
コンパクション（圧縮）：CMSと違って、G1は常にヒープ圧縮を行います。コンパクションは、長時間にわたって円滑かつ調和がとれた運用ができるように、潜在的な断片化問題を除去します。
Predictability. G1 is expected to be more predictable than CMS. This is largely due to the elimination of fragmentation issues that can negatively affect stop-the-world pause times in CMS. Additionally, G1 has a pause prediction model that, in many situations, allows it to often meet (or rarely exceed) a pause time target.
予測：G1はCMSよりも予測可能であることが期待されています。これは、CMSでのstop-the-worldに悪影響を与える断片化問題の除去による効果が大きいです。くわえて、G1は停止予測モデルを持っています。停止予測モデルは、さまざまな状況においてG1が停止時間目標に常に対応できる（または、停止時間目標を滅多に超過しない）ようにします。
1.2. Description（解説）
G1 takes a very different approach to heap layout than other HotSpot GCs. In G1, there is no physical separation between the young and old generations. Instead, there is a single contiguous heap which is split into same-sized regions. The young generation is a set of potentially non-contiguous regions, and the same is true for the old generation. This allows G1 to flexibly move resources as needed from the old to the young generation, and vice versa.
G1のヒープ設計に対する取り組みは、他のHotSpot GCとは異なります。G1では、Young世代領域とOld世代領域を物理的に分離しません。その代わりに、1つの連続したヒープ領域を、同サイズの領域に分離します。Young世代領域は、一組の非連続領域の場合もあります。Old世代領域も同様です。これは、G1が必要に応じてOld世代領域からYoung世代領域（逆方向も含む）へのリソース移動が柔軟にできるようにするためです。
Collection in G1 takes place through evacuation pauses, during which the survivors from regions referred to as the collection set are evacuated to another set of regions (the to-space) so that the collection set regions can then be reclaimed. Evacuation pauses are done in parallel, with all available CPUs participating. Most evacuation pauses collect the available young regions, thus are the equivalent of young collections in other HotSpot GCs. Occasionally, select old regions may also be collected during these pauses because G1 piggybacks old generation collection activity on young collections.
「退避停止」の間に、G1のコレクションが発生します。退避停止とは、生存オブジェクトが、「コレクションセット」と呼ばれる領域から、片方の領域（To領域）に退避される間ずっと停止されるものです。退避停止の目的は、コレクションセット領域を回復させるためです。退避停止は、すべての利用可能なCPUを利用して、パラレル（並列）に実行されます。ほとんどの退避停止では、利用可能なYoung世代領域に対して、他のHotSpot GCのYoung世代領域に対するコレクションと同様に、コレクションを実行します。時々、選ばれたOld世代領域に対しても、コレクションが実行される場合があります。これはG1がYoung世代領域に対するコレクション活動にOld世代領域に対するコレクション活動を乗せているためです（これを「ビギーバック方式」という）。
Like CMS, G1 periodically performs a concurrent marking phase. The main role of this phase is to identify which old regions are mostly full of garbage objects, as these are the most efficient and desirable to collect. Unlike CMS, G1 does not perform a concurrent sweeping phase. Instead, the most profitable old regions identified by the concurrent marking phase are collected during subsequent evacuation pauses (the piggybacking mentioned above).
CMSと同様に、G1は、周期的にコンカレント・マーキング・フェーズを実行します。このフェーズの主な役割は、どのOld世代領域が不要オブジェクト（ゴミ）で一杯になっているかを特定することです。これはコレクションを実行するのに、効率的で望ましいことだからです。CMSと違って、G1はコンカレント・スィーピング・フェーズを実行しません。その代わり、コンカレント・マーキング・フェーズで特定されたOld世代領域に対して、続いて発生する退避停止の間に、コレクションを実行します（前述のビギーバッキング方式）。
1.3. Using G1（G1の使用にあたって）
G1 is still considered experimental and can be enabled with the following two parameters:
G1はまだ実験段階ですが、次の2つのオプションで有効にすることができます。
-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC
|
To set a GC pause time goal, use the following parameter:
GC停止時間の最大目標値を設定するには、次のオプションを使用します。
-XX:MaxGCPauseMillis=50 (for a pause time target of 50ms)（停止時間目標を50ミリ秒に設定）
|
With G1, a time interval can be specified during which a GC pause should last no longer than the time given above:
次のオプションで、GC停止を合計で MaxGCPauseMillisミリ秒 まで許可するようにインターバル時間を設定することができます。
-XX:GCPauseIntervalMillis =200 (for a pause interval target of 200ms)（停止感覚目標を200ミリ秒に設定）
|
Note that the above two options represent goals, not promises or guarantees. They might work well in some situations but not in others, and the GC might not always be able to obey them.
注意：上の2つのオプションは、目標を設定するものであって、設定されたとおりに動作することを約束するものでも保障するものでもありません。いくつかの場面では設定された通りに動作しますが、そうでない場面もあります。CGは必ずしもそれらの設定値に従うことができるわけではありません。
Alternatively, the size of the young generation can be specified explicitly to impact evacuation pause times:
あるいは、退避停止時間を短縮させるために、Young世代領域のサイズを明示的に指定することもできます。
-XX:+G1YoungGenSize=512m (for a 512 megabyte young generation)（Young世代領域を512MBに設定）
|
G1 also uses the equivalent of survivor spaces, which are, naturally, a set of (potentially non-contiguous) regions. Their size can be specified with the usual parameters (e.g., -XX:SurvivorRatio=6).
G1も他のGCと同様にSurvivor領域を使用します。Survivor領域は従来とおりの一組の領域で、非連続領域の場合もあります。これらのサイズは、従来と同じオプションで設定することができます（例：-XX:SurvivorRatio=6）
Finally, to run G1 at its full potential, try setting these two parameters which are currently disabled by default because they may uncover a rare race condition:
最終的にこれらの2つのオプションを設定してみて、最大限の可能性でG1を実行してください。これらの2つのオプションは、まれに競合する可能性があるため、デフォルトでは無効になっています。
-XX:+G1ParallelRSetUpdatingEnabled -XX:+G1ParallelRSetScanningEnabled
|
One more thing to note is that G1 is very verbose compared to other HotSpot GCs when -XX:+PrintGCDetails is set. This is because it prints per-GC-thread timings and other information very helpful in profiling and trouble-shooting. If you want a more concise GC log, please switch to using -verbosegc (though it is recommended that the more detailed GC log be obtained).
注意：G1は、"-XX:+PrintGCDetails"オプションが設定されてるとき、他のHotSpot GCに比べてログ出力が冗長になります。これはGCのスレッドごとに、プロファイリングやトラブルシューティングに有用なタイミングや他の情報を出力するためです。出力を簡潔にしたい場合は、"-verbose"オプションを使ってください。ただし、詳細なGCログを出力することを推奨します。
1.4. Status（事情）
G1 development is now focused primarily on resolving any remaining reliability issues and improving performance, and also on removing the following limitations:
G1の開発は、未解決の信頼性問題の解決、性能の改良に主に焦点を合わせています。また、次の制限事項の解除にも焦点を合わせています。
l G1 does not fully support the JVM Tool Interface (JVM TI) or Java Management Extensions (JMX), so it is likely that monitoring and management tools will not work correctly with G1.
G1はJVM Tool Interface（JVMTI）とJava Management Extensions（JMX）を完全にサポートしていません。したがって、G1使用時は、モニタリングやマネジメントを行うツールは正常に動作しません。（訳注：JConsoleなどはG1GCに未対応ということ）
G1はJVM Tool Interface（JVMTI）とJava Management Extensions（JMX）を完全にサポートしていません。したがって、G1使用時は、モニタリングやマネジメントを行うツールは正常に動作しません。（訳注：JConsoleなどはG1GCに未対応ということ）
l G1 does not support incremental permanent generation collection. If an application does a lot of class unloading and requires permanent generation collection, this will be done during Full GCs.
G1はPermanent世代領域に対するインクリメント機能をサポートしていません。なお、アプリケーションが大量のクラスをアンロードし、Permanent世代領域に対するコレクションが必要となった場合に発生するFull GCにおいて、インクリメントが実行されます。
G1はPermanent世代領域に対するインクリメント機能をサポートしていません。なお、アプリケーションが大量のクラスをアンロードし、Permanent世代領域に対するコレクションが必要となった場合に発生するFull GCにおいて、インクリメントが実行されます。
l In terms of GC pause times, G1 is sometimes better and sometimes worse than CMS. Work is ongoing to make G1 consistently as good as, if not better than, CMS.
GC停止時間に関しては、G1は時々CMSよりよく、時々CMSより悪いです。G1がCMSよりよくない場合は、首尾一貫してCMSと同じくらいになるように、開発を行っています。
GC停止時間に関しては、G1は時々CMSよりよく、時々CMSより悪いです。G1がCMSよりよくない場合は、首尾一貫してCMSと同じくらいになるように、開発を行っています。
1.5. Resources（リソース）
l Description of HotSpot GCs: Memory Management in the Java HotSpot Virtual Machine White Paper: http://java.sun.com/j2se/reference/whitepapers/memorymanagement_whitepaper.pdf
l The original CMS paper: Printezis, T. and Detlefs, D. 2000. A generational mostly-concurrent garbage collector. In Proceedings of the 2nd international Symposium on Memory Management (Minneapolis, Minnesota, United States, October 15 - 16, 2000). http://portal.acm.org/citation.cfm?id=362422.362480 (requires access to ACM's portal)
l The original G1 paper: Detlefs, D., Flood, C., Heller, S., and Printezis, T. 2004. Garbage-first garbage collection. In Proceedings of the 4th international Symposium on Memory Management (Vancouver, BC, Canada, October 24 - 25, 2004). http://portal.acm.org/citation.cfm?id=1029879 (requires access to ACM's portal)
l G1 talk from JavaOne 2008: http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-5419&yr=2008
