Quest Java 7 new garbage collector G1 features

The G1 garbage collector (G1 GC) is the newly introduced garbage collector for the Java HotSpot VM in JDK 7, and the Java SE 6 Update 14 already contains a G1 experience version (according to 51CTO earlier, when the Java SE 6 U14 debut in early June, the original Su The statement of N is: the G1 garbage collector needs to be used by the charging party. Soon after, however, Sun said it was a misunderstanding, modified the original announcement, and said that the current and future use of G1 is completely free of charge, G1 is designed to replace hotspot low latency parallel marking/scavenging garbage collector (also known as CMS).

Java 7 G1 Properties

G1 is a server-side garbage collector with the following properties:

Parallelism and Concurrency: G1 leverages the parallelism existing in today's hardware, and when a Java application's thread is stopped, it uses all available CPUs (cores, hardware threads, etc.) to accelerate its stop, running Java threads to minimize the entire stack during the stop process.

Dai: Like other hotspot GC, G1 is a generation, means that it will be different when it comes to dealing with newly allocated objects (young generations) and objects that have been alive for some time (older generation), which focuses on garbage collection activities on new objects because they are the most likely to be recycled, and the old objects are only occasionally accessed, For most Java applications, Generation garbage collection has an important advantage over alternative scenarios.

Compression: Unlike CMS, G1 compresses the stack over time, eliminating potential fragmentation problems and ensuring smooth and consistent operation over long periods of time.

Predictability: G1 is better predictive than CMS, due to the benefits of eliminating fragmentation problems, the negative impact that occurs during a CMS stop, and the G1 has a pause forecast model that allows it to meet (or rarely exceed) a pause time target.

Java 7 G1 Description

Compared with other hotspot GC, G1 uses a very different stack layout method, in G1, there is no physical isolation between the younger generation and the older generation, instead, there is a continuous stack between them, divided into the same size area (region), and the younger generation may be a set of noncontiguous regions, The same is the case for older generations, which allows G1 to move resources flexibly between younger generations and older generations.

Recycling in G1 is done by eliminating pauses, during which the survivor refers to the return collection being transferred to another area so that the reclaimed area can regenerate, the elimination of the pause is parallel, all available CPUs will participate, most of the elimination pauses collect available young areas, and other hotspot The young recovery in the GC is the same, and occasionally the old-age area is recycled during the pause, as G1 is also responsible for the recovery of older generations in the younger generation.

As with CMS, G1 periodically performs a concurrent tag pause, the primary responsibility of which is to identify which old area's garbage objects are the most complete, because these are the most efficient and worthwhile to recycle, and unlike CMS, G1 does not perform concurrent purge pauses, instead, The most useful old areas are paused by a concurrent marker and are recycled during subsequent elimination pauses.

Using G1

G1 is still considered a test, and you can use the following two parameters to open it:

-xx:+unlockexperimentalvmoptions-xx:+useg1gc

To set a GC pause time target, use the following parameters:

-xx:maxgcpausemillis = 50 (pause time goal 50ms)

You can also specify a time interval when using G1, which can be used when the GC pause duration is not as long as the preceding time:

-xx:gcpauseintervalmillis = 200 (pause interval target 200ms)

Note that the above two options represent goals that are not committed and guaranteed, and in some cases they may be able to work, and GC is not always able to execute them.

In addition, the size of the younger generation can be explicitly specified to affect the elimination pause time:

-XX:+G1YOUNGGENSIZE=512M (Young generation size 512M)

G1 also uses the surviving space (possibly noncontiguous regions), and their size can be specified using a common parameter, such as:

-xx:survivorratio=6

Finally, in order to run G1 to its fullest potential, try setting the following two parameters that are disabled by default because they may expose a rare competitive state:

-XX:+G1ParallelRSetUpdatingEnabled

-XX:+G1ParallelRSetScanningEnabled

Note that when-xx:+printgcdetails is set, the G1 is much more verbose than the other hotspot GC because it prints the timing of each GC thread and other information that helps with troubleshooting, and if you want to make GC logs simpler, use the-VERBOSEGC parameter.

New developments in Java 7 G1

G1 development now focuses on legacy reliability issues and performance improvements, while also progressively removing the following restrictions:

G1 cannot fully support the JVM tool interface (JVM TI) or Java Management Extensions (JMX), so the monitoring and management tools for G1 are likely to not work properly;

G1 does not support incremental permanent generation recycling, and if an application produces many class dumps, it requires a permanent generation of recycling, which can be achieved during a full GC;

From GC pause time, G1 sometimes behaves better than CMS and sometimes worse than CMS.