Garbage-First (G1) Garbage Collector

Introduction to Garbage-First (G1) Garbage Collector

The Garbage-First (G1) garbage collector is targeted for multiprocessor machines scaling to a large amount of memory. It attempts to meet garbage collection pause-time goals with high probability while achieving high throughput with little need for configuration. G1 aims to provide the best balance between latency and throughput using current target applications and environments whose features include:

Heap sizes up to tens of GBs or larger, with more than 50% of the Java heap occupied with live data.
Rates of object allocation and promotion that can vary significantly over time.
A significant amount of fragmentation in the heap.
Predictable pause-time target goals that aren’t longer than a few hundred milliseconds, avoiding long garbage collection pauses.

G1 performs parts of its work at the same time as the application runs. It trades processor resources which would otherwise be available to the application for shorter collection pauses.

This is most visible in the use of one or more garbage collection threads active while the application runs. Thus, compared to throughput collectors, while garbage collection pauses are typically much shorter with the G1 collector, application throughput also tends to be slightly lower.

G1 is the default collector.

The G1 collector achieves high performance and tries to meet pause-time goals in several ways described in the following sections.

Enabling G1

The Garbage-First garbage collector is the default collector, so typically you don't have to perform any additional actions. You can explicitly enable it by providing -XX:+UseG1GC on the command line.

Basic Concepts

G1 is a generational, incremental, parallel, mostly concurrent, stop-the-world, and evacuating garbage collector which monitors pause-time goals in each of the stop-the-world pauses. Similar to other collectors, G1 splits the heap into (virtual) young and old generations. Space reclamation efforts concentrate on the young generation where it is most efficient to do so, with occasional space reclamation in the old generation

Some operations are always performed in stop-the-world pauses to improve throughput. Other operations that would take more time with the application stopped such as whole-heap operations like global marking are performed in parallel and concurrently with the application. To keep stop-the-world pauses short for space reclamation, G1 performs space reclamation incrementally in steps and in parallel. G1 achieves predictability by tracking information about previous application behavior and garbage collection pauses to build a model of the associated costs. It uses this information to size the work done in the pauses. For example, G1 reclaims space in the most efficient areas first (that is the areas that are mostly filled with garbage, therefore the name).

G1 reclaims space mostly by using evacuation: live objects found within selected memory areas to collect are copied into new memory areas, compacting them in the process. After an evacuation has been completed, the space previously occupied by live objects is reused for allocation by the application.

The Garbage-First collector is not a real-time collector. It tries to meet set pause-time targets with high probability over a longer time, but not always with absolute certainty for a given pause.

Heap Layout

G1 partitions the heap into a set of equally sized heap regions, each a contiguous range of virtual memory as shown in Figure 7-1. A region is the unit of memory allocation and memory reclamation. At any given time, each of these regions can be empty (light gray), or assigned to a particular generation, young or old. As requests for memory comes in, the memory manager hands out free regions. The memory manager assigns them to a generation and then returns them to the application as free space into which it can allocate itself.

Figure 7-1 G1 Garbage Collector Heap Layout

Description of "Figure 7-1 G1 Garbage Collector Heap Layout "

The young generation contains eden regions (red) and survivor regions (red with "S"). These regions provide the same function as the respective contiguous spaces in other collectors, with the difference that in G1 these regions are typically laid out in a noncontiguous pattern in memory. Old regions (light blue) make up the old generation. Old generation regions may be humongous (light blue with "H") for objects that span multiple regions.

An application always allocates into a young generation, that is, eden regions, with the exception of humongous objects that are directly allocated as belonging to the old generation.

Garbage Collection Cycle

On a high level, the G1 collector alternates between two phases. The Young-Only phase contains garbage collections that fill up the currently available memory with objects in the old generation gradually. The Space-Reclamation phase is where G1 reclaims space in the old generation incrementally, in addition to handling the young generation. Then the cycle restarts with a Young-Only phase.

Figure 7-2 gives an overview about this cycle with an example of the sequence of garbage collection pauses that could occur:

Figure 7-2 Garbage Collection Cycle Overview

Description of "Figure 7-2 Garbage Collection Cycle Overview "

The following list describes the phases, their pauses and the transition between the phases of the G1 garbage collection cycle in detail:

Young-Only phase: This phase starts with a few Normal young collections that promote objects into the old generation. The transition between the Young-Only phase and the Space-Reclamation phase starts when the old generation occupancy reaches a certain threshold, the Initiating Heap Occupancy threshold. At this time, G1 schedules a Concurrent Start young collection instead of a Normal young collection.
- Concurrent Start : This type of collection starts the marking process in addition to performing a Normal young collection. Concurrent marking determines all currently reachable (live) objects in the old generation regions to be kept for the following Space-Reclamation phase. While marking hasn’t completely finished, Normal young collections may occur. Marking finishes with two special stop-the-world pauses: Remark and Cleanup.
  
  The Concurrent Start pause may also determine that there is no need to follow through with marking: in this case, a short Concurrent Mark Undo phase occurs, and the Young-Only phase continues. In this case no Remark and Cleanup pauses will occur.
- Remark: This pause finalizes the marking itself, performs reference processing and class unloading, reclaims completely empty regions and cleans up internal data structures. Between Remark and Cleanup G1 calculates information to later be able to reclaim free space in selected old generation regions concurrently, which will be finalized in the Cleanup pause.
- Cleanup: This pause determines whether a Space-Reclamation phase will actually follow. If a Space-Reclamation phase follows, the Young-Only phase completes with a single Prepare Mixed young collection.
Space-Reclamation phase: This phase consists of multiple young collections that in addition to young generation regions, also evacuate live objects of sets of old generation regions. These collections are also called Mixed collections. The Space-Reclamation phase ends when G1 determines that evacuating more old generation regions wouldn't yield enough free space worth the effort.

After Space-Reclamation, the collection cycle restarts with another Young-Only phase. As backup, if the application runs out of memory while gathering liveness information, G1 performs an in-place stop-the-world full heap compaction (Full GC) like other collectors.

Garbage Collection Pauses and Collection Set

G1 performs garbage collections and space reclamation in stop-the-world pauses. Live objects are typically copied from source regions to one or more destination regions in the heap, and existing references to these moved objects are adjusted.

For non-humongous regions, the destination region for an object is determined from the source region of that object:

Objects of the young generation (eden and survivor regions) are copied into survivor or old regions, depending on their age.
Objects from old regions are copied to other old regions.

Objects in humongous regions are treated differently. G1 only determines their liveness, and if they are not live, reclaims the space they occupy. G1 only moves humongous objects in a very slow last-resort collection effort.

Remembered Set

To evacuate the collection set G1 manages a remembered set: the set of locations outside the collection set that contain references into the collection set. When an object from the collection set moves during garbage collection, any other references to that object from outside the collection set need to be changed to point to the new location of the object.

The remembered set entries represent approximate locations to save memory: often references close together reference objects close together. G1 logically partitions the heap into cards, by default 512 byte sized areas. Remembered set entries are compressed indexes of these cards.

G1 initially manages this remembered set on a per-region basis: every region contains a per-region remembered set, the set of locations with potential references into this region. During garbage collection, the remembered set for the entire collection set is generated from these.

The remembered sets are created mostly lazily: between the Remark and Cleanup pause G1 rebuilds the remembered set of all marking collection set candidate regions. Other than that G1 always maintains remembered sets for young generation regions as they are collected at every collection.

Collection Set

The collection set is the set of source regions to reclaim space during garbage collection. Independent of the garbage collection type, the collection set consists of different kinds of regions:

Young generation regions,
Humongous regions. See Humongous Objects about the restrictions,
Collection set candidate regions. These are old generation regions that G1 determined to be good candidate regions for garbage collection due to their high collection efficiency.
This efficiency is calculated from the amount of free space, where regions with little live data are preferred over regions that contain mostly live data, and the connectivity to other regions, low connectivity being preferred over high connectivity.

There are two sources for old generation collection set candidate regions: from whole heap analysis, i.e., the marking, when G1 has good information about the liveness and connectivity of all old generation regions, and regions that experienced evacuation failure.

The former region's efficiencies have been determined directly using up-to-date liveness and connectivity data gathered in the preceding concurrent mark.

The objects that G1 has not been able to evacuate during an evacuation failure are typically very few. This makes them very efficient regions to collect by default.

Garbage Collection Process

A garbage collection consists of four phases.

The Pre Evacuate Collection Set phase performs some preparatory work for garbage collection: disconnecting TLABs from mutator threads, selecting the collection set for this collection as described in Java Heap Sizing, and other small preparatory work.
During Merge Heap Roots G1 creates a single unified remembered set for later easier parallel processing from the collection set regions. This removes many duplicates from the individual remembered sets that would otherwise be needed to be filtered out later in a more expensive way.
The Evacuate Collection Set phase contains the bulk of the work: G1 starts moving objects starting from the roots. A root reference is a reference from outside the collection set, either from some VM internal data structure (external roots), code (code roots) or from the remainder of the Java heap (heap roots). For all roots, G1 copies the referenced object in the collection set to its destination, processes its references into the collection set as new roots until there are no more roots.

Individual timing for these phases can be observed with -Xlog:gc+phases=debug logging in the Ext Root Scanning, Code Root Scan, Scan Heap Roots, and Object Copy sub-phases respectively.

G1 may optionally repeat main evacuation phases for optional collection sets.
The Post Evacuate Collection Set consists of clean-up work including reference processing and setup for the following mutator phase.

These phases correspond to the phases printed with -Xlog:gc+phases=info logging.

Garbage-First Internals

This section describes some important details of the Garbage-First (G1) garbage collector.

Java Heap Sizing

G1 respects standard rules when resizing the Java heap, using -XX:InitialHeapSize as the initial Java heap size, -XX:MaxHeapSize as the maximum Java heap size, -XX:MinHeapFreeRatio for the minimum percentage of free memory, and -XX:MaxHeapFreeRatio for determining the maximum percentage of free memory after resizing. The G1 collector resizes the Java heap according to these options during the Remark and Full GC pauses only. This process may release memory to or allocate memory from the operating system.

Heap expansion occurs within the collection pause, while memory release occurs after the pause concurrent with the application.

Young-Only Phase Generation Sizing

G1 determines an initial size for the young generation at the end of a normal young collection for the next mutator phase. As the mutator phase progresses, G1 refines this size estimate regularly.

The -XX:GCPauseIntervalMillis and -XX:MaxGCPauseTimeMillis options provide G1 with a minimum mutator utilization (MMU) to fit pause times into. For every possible time range of -XX:GCPauseIntervalMillis, G1 adapt the collection pauses to at most use -XX:MaxGCPauseTimeMillis milliseconds for garbage collection pauses. Information used for this calculation includes previous observations on how long it took young generations of similar size to evacuate, information on how many objects had to be copied during collection, and how interconnected these objects had been.

The options -XX:G1NewSizePercent and -XX:G1MaxNewSizePercent constrain the minimum and maximum eden size, which in turn constrain garbage collection pause times. The Garbage-First Garbage Collector Tuning guide provides some examples on how to decrease maximum pauses using these.

Alternatively, -XX:NewSize in combination with -XX:MaxNewSize may be used to set the minimum and maximum young generation sizes respectively.

At the start of a normal young collection, G1 selects additional old generation regions based on available time, as mentioned in the Collection Set section.

Note:

Only specifying one of these latter options to set eden size fixes young generation size to exactly the value passed with -XX:NewSize and -XX:MaxNewSize respectively. This disables pause time control.

Space-Reclamation Phase Generation Sizing

During the Space-Reclamation phase, G1 tries to maximize the amount of space that will be reclaimed in the old generation in a single garbage collection pause. The size of the young generation is typically set to the minimum allowed, typically as determined by -XX:G1NewSizePercent, but also considering the MMU specification.

At the start of every Mixed collection in this phase, G1 determines the collection set from regions as described in the Collection Set section. The amount of old generation regions in the collection set is determined as follows:

A minimum set of old generation regions to ensure evacuation progress. This set of old generation regions is determined by the number of old generation regions determined as collection set candidates by the marking divided by the length of the Space-Reclamation phase as determined by -XX:G1MixedGCCountTarget.
Additional old generation regions from the collection set candidates if G1 predicts that after collecting the minimum set there will be time left. Old generation regions are added until 80% of the remaining time is predicted to be used.
A set of optional collection set regions that G1 evacuates incrementally after the other two parts have been evacuated and there is time left in this pause.

G1 collects the first two sets of regions in an initial garbage collection pass, with additional collection passes with regions from the optional collection set fit into the remaining pause time. This method ensures space reclamation progress while improving the probability to keep pause time and minimal overhead due to management of the optional collection set.

The Space-Reclamation phase ends when there are no more marking candidate regions in the collection set candidate regions set.

See Garbage-First Garbage Collector Tuning for more information about how many old generation regions G1 will use and how to avoid long mixed collection pauses.

Periodic Garbage Collections

If there has been no garbage collection for a long time because of application inactivity, the VM may unnecessarily hold on to a large amount of unused memory for a long time that could be used elsewhere. To avoid this, G1 can be forced to do regular garbage collection using the -XX:G1PeriodicGCInterval option during long idle periods. This option determines a minimum interval in milliseconds at which G1 considers performing a garbage collection after detecting the idle application state. If this amount of time passed since any previous garbage collection pause and there is no concurrent cycle in progress, G1 triggers additional garbage collections with the following possible effects:

During the Young-Only phase: G1 starts a concurrent marking using a Concurrent Start pause or, if -XX:-G1PeriodicGCInvokesConcurrent has been specified, a Full GC.
During the Space-Reclamation phase: G1 continues the space reclamation phase triggering the garbage collection pause type appropriate to current progress.

The -XX:G1PeriodicGCSystemLoadThreshold option should be used to refine what idle means for G1: if the average one-minute system load value as returned by the getloadavg() call on the JVM host system (for example, a container) is above this value, the VM is not considered idle and no periodic garbage collection will be run.

See JEP 346: Promptly Return Unused Committed Memory from G1 for more information about periodic garbage collections.

Determining Initiating Heap Occupancy

The Initiating Heap Occupancy Percent (IHOP) is the threshold at which a Concurrent Start collection is triggered and it is defined as a percentage of the old generation size.

G1 by default automatically determines an optimal IHOP by observing how long marking takes and how much memory is typically allocated in the old generation during marking cycles. This feature is called Adaptive IHOP. If this feature is active, then the option -XX:InitiatingHeapOccupancyPercent determines the initial value as a percentage of the size of the current old generation as long as there aren't enough observations to make a good prediction of the Initiating Heap Occupancy threshold. Turn off this behavior of G1 using the option-XX:-G1UseAdaptiveIHOP. In this case, the value of -XX:InitiatingHeapOccupancyPercent always determines this threshold.

Internally, Adaptive IHOP tries to set the Initiating Heap Occupancy so that the first Mixed garbage collection of the Space-Reclamation phase starts when the old generation occupancy is at a current maximum old generation size minus the value of -XX:G1HeapReservePercent as the extra buffer.

Marking

G1 marking uses an algorithm called Snapshot-At-The-Beginning (SATB). It takes a virtual snapshot of the heap at the time of the Concurrent Start pause. All objects that were live at the start of marking are considered live for the remainder of marking. This means that objects that become dead (unreachable) during marking are still considered live for the purpose of space reclamation (with some exceptions). This may cause some additional memory wrongly retained compared to other collectors. However, SATB potentially provides better latency during the Remark pause. The too conservatively considered live objects during that marking will be reclaimed during the next marking. See the Garbage-First Garbage Collector Tuning topic for more information about problems with marking.

Evacuation Failure

Evacuation failure means that G1 could not move objects during garbage collections.

Such an occurrence is indicated in garbage collection logs with -Xlog:gc logging using the Evacuation Failure: <reason> tag where <reason> is one or both of Allocation and Pinned as indicated in the example below:

[9,740s][info ][gc] GC(26) Pause Young (Normal) (G1 Evacuation Pause) (Evacuation Failure: Allocation/Pinned) 2159M->402M(3000M) 6,108ms

Allocation: G1 could not find enough space in the destination area to move the object to.
Pinned: There is an object that G1 could not move because G1 found an object that has been locked in place, or pinned, to allow safe use of native code on it using the GetPrimitiveArrayCritical() JNI call. See JEP 423: Region Pinning for G1 for more information about pinning objects.

If G1 cannot move all objects out of a region, that region will be unavailable for allocation temporarily. G1 schedules these regions for immediate evacuation in the next garbage collections as collection set candidates.

In the worst case, if garbage collection does not manage to free any space at all during a garbage collection, G1 will schedule a Full GC. This type of collection performs in-place compaction of the entire heap. This might be very slow.

See Garbage-First Garbage Collector Tuning for more information about problems with allocation failure or Full GCs before signaling out of memory.

Humongous Objects

Humongous objects are objects larger or equal the size of half a region. The current region size is determined ergonomically as described in the Ergonomic Defaults for G1 GC section, unless set using the -XX:G1HeapRegionSize option.

These humongous objects are sometimes treated in special ways:

Every humongous object gets allocated as a sequence of contiguous regions in the old generation. The start of the object itself is always located at the start of the first region in that sequence. Any leftover space in the last region of the sequence will be lost for allocation until the entire object is reclaimed.
Generally, humongous objects can be reclaimed only at the end of marking during the Remark pause, or during Full GC if they became unreachable. There is, however, a special provision for humongous objects for arrays of primitive types for example, bool, all kinds of integers, and floating point values. G1 opportunistically tries to reclaim humongous objects if they are not referenced by many objects at any garbage collection pause. This behavior is enabled by default but you can disable it with the option -XX:-G1EagerReclaimHumongousObjects.
Allocations of humongous objects may cause garbage collection pauses to occur prematurely. G1 checks the Initiating Heap Occupancy threshold at every humongous object allocation and may force a Concurrent Start young collection immediately, if current occupancy exceeds that threshold and no marking is currently in progress.
Humongous objects only move in a last-resort collection effort after the first Full GC failed to free enough contiguous memory for a humongous object allocation in a second Full GC in the same pause. This process is very slow. Due to unusable space in heap regions containing the end of humongous objects, it is still possible that G1 exits the VM with an out-of-memory condition.

Ergonomic Defaults for G1 GC

This topic provides an overview of the most important defaults specific to G1 and their default values. They give a rough overview of expected behavior and resource usage using G1 without any additional options.

Table 7-1 Ergonomic Defaults G1 GC

Option and Default Value	Description
`-XX:MaxGCPauseMillis=200`	The goal for the maximum pause time.
`-XX:GCPauseTimeInterval`=<ergo>	The goal for the maximum pause time interval. By default G1 doesn’t set any goal, allowing G1 to perform garbage collections back-to-back in extreme cases.
`-XX:ParallelGCThreads`=<ergo>	The maximum number of threads used for parallel work during garbage collection pauses. This is derived from the number of available threads of the computer that the VM runs on in the following way: if the number of CPU threads available to the process is fewer than or equal to 8, use that. Otherwise add five eighths of the threads greater than to the final number of threads. At the start of every pause, the maximum number of threads used is further constrained by maximum total heap size: G1 will not use more than one thread per `-XX:HeapSizePerGCThread` amount of Java heap capacity.
`-XX:ConcGCThreads`=<ergo>	The maximum number of threads used for concurrent work. By default, this value is `-XX:ParallelGCThreads` divided by 4.
`-XX:+G1UseAdaptiveIHOP` `-XX:InitiatingHeapOccupancyPercent=45`	Defaults for controlling the initiating heap occupancy indicate that adaptive determination of that value is turned on, and that for the first few collection cycles G1 will use an occupancy of 45% of the old generation as mark start threshold.
`-XX:G1HeapRegionSize=<ergo>`	The size of the heap regions. The default value is based on the maximum heap size and it is calculatedto render roughly 2048 regions, with a maximum ergonomically determined value of 32 MB. A size given by the user must be a power of 2, and valid values range from 1 to 512 MB.
`-XX:G1NewSizePercent=5` `-XX:G1MaxNewSizePercent=60`	The size of the young generation in total, which varies between these two values as percentages of the current Java heap in use.
`-XX:G1HeapWastePercent=5`	The allowed unreclaimed space in the heap as a percentage of current total heap size. G1 stops adding old generation regions to the marking collection set candidates if the total free space after collecting these regions is lower than that value.
`-XX:G1MixedGCCountTarget=8`	The expected length of the Space-Reclamation phase in a number of collections.
`-XX:G1MixedGCLiveThresholdPercent=85`	Old generation regions with higher live object occupancy than this percentage will not be collected in a Space-Reclamation phase.

Note:

<ergo> means that the actual value is determined ergonomically depending on the environment.

Comparison to Other Collectors

This is a summary of the main differences between G1 and the other collectors:

Parallel GC can compact and reclaim space in the old generation only as a whole. G1 incrementally distributes this work across multiple much shorter collections. This substantially shortens pause time at the potential expense of throughput.
G1 performs part of the old generation Space-Reclamation concurrently.
G1 may exhibit higher overhead than the above collectors, affecting throughput due to its concurrent nature.
ZGC aims to provide significantly smaller pause times at further cost of throughput.

Due to how it works, G1 has some mechanisms to improve garbage collection efficiency:

G1 can reclaim some completely empty, large areas of the old generation during any collection. This could avoid many otherwise unnecessary garbage collections, freeing a significant amount of space without much effort.
G1 can optionally try to deduplicate duplicate strings on the Java heap concurrently.

Reclaiming empty, large objects from the old generation is always enabled. You can disable this feature with the option -XX:-G1EagerReclaimHumongousObjects. String deduplication is disabled by default. You can enable it using the option -XX:+G1EnableStringDeduplication.