The Garbage-first (G1) collector since Oracle JDK 7 update 4 and later releases

• Refer to http://www.oracle.com/technetwork/tutorials/tutorials-1876574.html for detail.
• Some of the content is copied here.

The G1 garbage Collector

The Garbage-first (G1) collector is a server-style garbage collector, targeted for multi-processor machines with large mem Ories. It meets Garbage collection (GC) Pause time goals with a high probability, while achieving high throughput. The G1 garbage collector is fully supported in Oracle JDK 7 update 4 and later releases. The G1 Collector is designed for applications that:

• Can operate concurrently with applications threads like the CMS collector.
• Compact free space without lengthy GC induced pause times.
• Need more predictable GC pause durations.
• Do not want to sacrifice a lot of throughput performance.
• Do not require a much larger Java heap.

G1 is planned as the long term replacement for the Concurrent Mark-sweep Collector (CMS). Comparing G1 with CMS, there is differences that make G1 a better solution. One difference is this G1 is a compacting collector. G1 compacts sufficiently to completely avoid the use of fine-grained free lists for allocation, and instead relies on Regi Ons. This considerably simplifies parts the collector, and mostly eliminates potential fragmentation issues. Also, G1 offers more predictable garbage collection pauses than the CMS collector, and allows users to specify desired PAU SE targets.

G1 Operational Overview

The older garbage collectors (serial, parallel, CMS) all structure the heap to three Sections:young generation, Old Gen Eration, and permanent generation of a fixed memory size.

All memory objects end up in one of these three sections.

The G1 collector takes a different approach.

The heap is partitioned to a set of equal-sized heap regions, each a contiguous range of virtual memory. Certain region sets was assigned the same roles (Eden, Survivor, old) as in the older collectors, but there was not a fixed size for them. This provides greater flexibility in memory usage.

When performing garbage collections, G1 operates in a manner similar to the CMS collector. G1 performs a concurrent global marking phase to determine the liveness of objects the heap. After the mark phase completes, G1 knows which regions is mostly empty. It collects in these regions first, which usually yields a large amount of free space. This is a garbage collection is called Garbage-first. As the name suggests, G1 concentrates its collection and compaction activity in the areas of the heap that is likely to B e Full of Reclaimable objects, which is, garbage. G1 uses a pause prediction model to meet a user-defined pause time target and selects the number of regions to collect BAS Ed on the specified pause time target.

The regions identified by G1 as ripe for reclamation is garbage collected using evacuation. G1 copies objects from one or more regions of the "heap to a" on the heap, and in the process both compacts an D frees up memory. This evacuation was performed in parallel on multi-processors, to decrease pause times and increase throughput. Thus, with all garbage collection, G1 continuously works to reduce fragmentation, working within the user defined pause T IMEs. This is beyond the capability of both the previous methods. CMS (Concurrent Mark Sweep) garbage collector does not do compaction. Parallelold garbage Collection performs only whole-heap compaction, which results in considerable pause times.

It's important to note, G1 is not a real-time collector. It meets the set pause time target with high probability and not absolute certainty. Based on data from previous collections, G1 does an estimate of what many regions can be collected within the user Specifie D Target time. Thus, the collector have a reasonably accurate model of the cost of collecting the regions, and it uses this model to deter Mine which and how many regions to collect while staying within the pause time target.

Note: G1 have both concurrent (runs along with application threads, e.g., refinement, marking, cleanup) and parallel (Multi-threa Ded, e.g, stop the world) phases. Full garbage collections is still single threaded, and if tuned properly your applications should avoid full GCs.

G1 Footprint

If you migrate from the PARALLELOLDGC or CMS collector to G1, you'll likely see a larger JVM process size. This was largely related to "accounting" data structures such as remembered sets and Collection sets.

remembered sets or Rsets track object references to a given region. There is one RSet per region in the heap. The RSet enables the parallel and independent collection of a region. The overall footprint impact of rsets is less than 5%.

Collection sets or csets the set of regions that would be collected in a GC. All live data in a CSet is evacuated (copied/moved) during a GC. Sets of regions can is Eden, survivor, and/or old generation. Csets has a less than 1% impact on the size of the JVM.

Recommended use Cases for G1

The first focus of G1 is to provide a solution for users running applications, require large heaps with limited GC lat Ency. This means heap sizes of around 6GB or larger, and stable and predictable pause time below 0.5 seconds.

Applications running today with either the CMS or the PARALLELOLDGC garbage collector would benefit switching to G1 if the Application have one or more of the following traits.

• Full GC durations is too long or too frequent.
• The rate of object allocation or promotion varies significantly.
• Undesired long garbage collection or compaction pauses (longer than 0.5 to 1 second)

Note: If you are using a CMS or PARALLELOLDGC and your application is not experiencing long garbage collection pauses, it is fine To stay with your current collector. Changing to the G1 collector are not a requirement for using the latest JDK.

The Garbage-first (G1) collector since Oracle JDK 7 update 4 and later releases