欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识！
您现在的位置是： 首页

The Garbage-First Garbage Collector 博客分类： 技术 CMSJVMJ2SEAccessSUN 

程序员文章站 2024-03-19 17:30:01
...

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).

Attributes

G1 is a “server-style” GC and has the following attributes.

  • 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.
  • 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.
  • Compaction. Unlike CMS, G1 performs heap compaction over time. Compaction eliminates potential fragmentation problems to ensure smooth and consistent long-running operation.
  • 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.

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.

Collection in G1 takes place through evacuation pauses, during which the survivors from a set of 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.

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).

Using G1

G1 is still considered experimental and can be enabled with the following two parameters:

-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC

To set a GC pause time goal, use the following parameter:

-XX:MaxGCPauseMillis =50 (for a pause time target of 50ms)

With G1, a time interval can be specified during which a GC pause should last no longer than the time given above:

-XX:GCPauseIntervalMillis =200 (for a pause interval target of 200ms)

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.

Alternatively, the size of the young generation can be specified explicitly to impact evacuation pause times:

-XX:+G1YoungGenSize=512m (for a 512 megabyte young generation)

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).

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:

-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).

Status

G1 development is now focused primarily on resolving any remaining reliability issues and improving performance, and also on removing the following limitations:

  • 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 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.
  • 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.

Resources

相关标签： CMS JVM J2SE Access SUN

上一篇： Javascript闭包（Closure） 博客分类： javascript JavaScriptIE 

下一篇： 塔木德 博客分类： 生活、哲理  

推荐阅读