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 may occur within any garbage collection pause. If G1 determines that the Java heap should be shrunk, the release of this memory occurs after the pause concurrent with the application after the pause.

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 garbage collection activity into. For every possible time range of -XX:GCPauseIntervalMillis, G1 sizes 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 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 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.

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

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 determined the same as for other Young-Only phase garbage collections, additionally taking the minimum set of old generation regions to take into the collection set into account.

At the start of every Mixed collection in this phase, G1 determines the collection set from regions as described in the 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 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  topic for more information about problems with marking.

Evacuation Failure

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

Such an occurrence is indicated in garbage collection logs with -Xlog:gc logging using an Evacuation Failure: <reason> printout 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

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 garbage collection performs in-place compaction of the entire heap. This might be very slow.

See 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 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 a first Full GC failed to free enough contiguous memory for another humongous object allocation in a second Full GC in the same pause. This process is very slow. Due to space being unavailable for allocation in heap regions containing the end of humongous objects, it is still possible that G1 exits the VM with an out-of-memory condition.