Understanding G1 Garbage Collector in Java

G1GC Intro to G1GC the latency collector

Overview G1GC 1. Generational based (this means the log do not have Young, Terenure, Old) ~ Latency collector 2. Default JDK 11 GC, can be used in JDK 8 3. Snap shot at the beginning of the marking cycle 4. Divides the heap in regions and correlate them with the generations 5. G1GC strives to match the latency target (soft real time goal) 6. If the objects are too big(half of the region or more), you might have humongous problems 7. G1GC avoids fragmentation (CMS problem) with a compaction phase at the end (small, adjustable but still a pause). 8. G1GC might not do so well with JNI

Comparing with G1 Garbage Collector G1 Garbage Collector: Regionalized and Generational GC G1GC divides the heap and correlates the regions to generations not continuously. Shenandoah divides the heap into regions, so it is called a regionalized GC. Those regions have separated threads, working at the same time, which improve the performance. Comparison between G1GC vs Shenandoah on this solution

Regions (default is 2048) E O U S E O S E O S E S O E eden O old S survivor U unassigned The bigger the heap, the bigger the regions

Core part of G1GC is the latency Its heuristic is to not trigger a full GC unless absolutely necessary. The core flag will be MaxGCPauseMillis Sets a maximum pause time value. The default value is 200 milliseconds

Regions size vs size of the heap <4GiB - 1MiB <8GiB - 2MiB <16GiB - 4MiB <32GiB - 8MiB <64GiB - 16MiB 64GiB+ - 32MiB You can overwrite this with G1HeapRegionSize

Snapshot at the beginning Snapshot-At-The-Beginning (SATB) algorithm (instead of incremental update. So basically G1Gc takes a snapshot of the live set objects in the heap right in the marking cycle and then the decision are taking in that time, including the threshold and for mixed regions. Young garbage collections are allowed - during the concurrent cycle - and this basically avoids the stop of the world events. And this is triggered with those thresholds, ie. when the young regions fills it up. So the objects at the beginning of that cycle that matter here most.

Generations Four types of generations: - - - - Eden Tenure Old Free | unassigned Young Survival Old Native memory Metaspace

G1GC Algorithm 1. Heap divided into regions regionalized 2. Correlate each region with a generation generational 3. Eden starts empty and is filled with new data allocations. 4. Eden fills up triggering the end of the epoch and the Evacuation phase. 5. The live data in Eden and Survivor From is moved (evacuated) into Survivor To space, with the exception of any data promoted from Survivor From to Tenured. 6. After the Evacuation phase, Eden and Survivor From are devoid of live data and reclaimed. 7. Compaction occurs at the end (avoid CMS compaction issue)

GC phases - Minor GCs to clean the Eden ~ survivor from survivor to - Mixed collection: Minor + reclaimed regions of Tenured - Full GC to clean all regions mostly old - Full GCs to rescale the Metaspace

G1GC flow IHOP reached % liveness concurrent marking cycle (SATB) young object collection mixed collection calculate % old region If >G1HeapWastePercent, mixed collections continue

Stop the World - STW STW does stop all threads, i.e. allocation app threads, except for GC threads (compiler threads, a service thread, a VM thread etc) Any event that interrupt the application time: - Minor GCs - Full GCs

Tuning G1GC 1. 2. 3. 4. 5. Increasing the regions sizes (Xmn for instance) Increasing the number of threads Changing the rate of young vs old Adjust compaction phase cannot do that in CMS Mixed regions taming Consult solution https://access.redhat.com/solutions/2162391

Issue: humongous object Objects that have a size of the regions will be treated separately and can cause trouble Such an object is allocated directly in the old generation into "Humongous regions" Humongous allocations always trigger a concurrent marking cycle, whether the IHOP criteria is met or not. Solution Increasing the regions sizes Consult solution https://access.redhat.com/solutions/2162391

Example of tuning flags in G1GC 1. -Xmn2g Max New Size max size of young gen 2. -XX:NewSize=1g New Size min/initial size of young gen 3. -XX:G1ReservePercent=30 Sets the percentage of reserve memory to keep free so as to reduce the risk of to-space overflows. Scenario 1: the old generation is taking everything may be useful to set a lower boundary NewSize Scenario 2: the volatility is very high set the max new size; you can even set both the same

Experimental flags Some flags are experimental: G1NewSizePercent; G1MaxNewSizePercent So one must use +UnlockExperimentalVMOptions Example: > java -XX:+UnlockExperimentalVMOptions -XX:G1NewSizePercent=10 - XX:G1MaxNewSizePercent=75 G1test.jar

Mixed collections - liveness percentage A mixed collection works almost exactly like a young collection, with two major differences. First, a mixed collection is also going to collect, evacuate and compact a select set of old regions. Second, mixed collections are not based on the same evacuation triggers a young collection uses. They operate with the goal of collecting as quickly and as frequently as possible. If an Old region has fewer live objects than the percentage defined by G1MixedGCLiveThresholdPercent 85% (JDK8u40+) live, do not collect and evacuate it during this mixed cycle.

Adaptive behavior IHOP is used as reference but the behavior is adaptative To disable this behavior, -XX:-G1UseAdaptiveIHOP

G1GC Logs 2015-09-14T12:35:27.263-0700: 183.216 Here 2015-09-14T12:35:27.263-0700 indicates the time at which this GC event fired. Here 183.216 indicates that 183 seconds after the Java process was started this GC event was fired. Full GC (Allocation Failure) indicates that this is a Full GC event, triggered because of allocation failure. When the heap is fragmented, direct allocations in the Old generation may fail even when there is a lot of free space, this will typically cause Allocation Failure. [Eden: 3072.0K(194.0M)->0.0B(201.0M) Survivors: 0.0B->0.0B Heap: 3727.1M(4022.0M)->3612.0M(4022.0M)], [Metaspace: 2776K->2776K(1056768K)] This line indicates the heap size changes, because of this Full GC event: Eden: 3072.0K(194.0M)->0.0B(201.0M) - indicates that Eden generation s capacity was 194mb, in that 3072kb was occupied. After this GC event, young generation occupied size came down to 0. Target Capacity of Eden generation has been increased to 201mb, but not yet committed. Additional regions are added to Eden generation, as demands are made. Survivors: 0.0B->0.0B indicates that survivor space was 0 bytes before and after this event. Heap: 3727.1M(4022.0M)->3612.0M(4022.0M) - indicates that capacity of heap size was 4022mb, in that 3727.1mb was utilized. After this GC event, heap utilization dropped to 3612mb. 115.1mb (i.e. 3727.1 3612) of objects has been garbage collected in this event. And heap capacity has remained at 4022mb. Metaspace: 2776K->2776K(1056768K) indicates that before the GC event it s occupied size was 2776k and after the GC event also it s occupied size was 2776k. Basically, it implies metaspace utilization remained consistent in this phase. The total capacity of metaspace was 1056768k. Times: user=19.08, sys=0.01, real=9.74 secs here note the 'real' time, it indicates this GC event took 9.74 seconds to complete, which is a very high pause time. 1. 2. 3. 4.

Interpreting G1GC Logs Full GC (Allocation Failure) indicates that this is a Full GC event, triggered because of allocation failure. When the heap is fragmented, direct allocations in the Old generation may fail even when there is a lot of free space, this will typically cause Allocation Failure. [Eden: 3072.0K(194.0M)->0.0B(201.0M) Survivors: 0.0B->0.0B Heap: 3727.1M(4022.0M)->3612.0M(4022.0M)], [Metaspace: 2776K- >2776K(1056768K)] Indicates the heap size changes, because of this Full GC event: Eden: 3072.0K(194.0M)->0.0B(201.0M) indicates that Eden generation s capacity was 194mb, in that 3072kb was occupied. After this GC event, young generation occupied size came down to 0. Target Capacity of Eden generation has been increased to 201mb, but not yet committed. Additional regions are added to Eden generation, as demands are made. Survivors: 0.0B->0.0B indicates that survivor space was 0 bytes before and after this event. Heap: 3727.1M(4022.0M)->3612.0M(4022.0M) - indicates that capacity of heap size was 4022mb, in that 3727.1mb was utilized. After this GC event, heap utilization dropped to 3612mb. 115.1mb (i.e. 3727.1 3612) of objects has been garbage collected in this event. And heap capacity has remained at 4022mb. Metaspace: 2776K->2776K(1056768K) indicates that before the GC event it s occupied size was 2776k and after the GC event also it s occupied size was 2776k. Basically, it implies metaspace utilization remained consistent in this phase. The total capacity of metaspace was 1056768k. Times: user=19.08, sys=0.01, real=9.74 secs here note the 'real' time, it indicates this GC event took 9.74 seconds to complete, which is a very high pause time.

Specific tuning flags vs behavior G1MixedGCLiveThresholdPercent Threshold for regions to be considered for inclusion in the collection set of mixed GCs. Regions with live bytes exceeding this will not be collected. Range 0 - 100

Relevant Solutions G1Gc Reference Object Humongous allocation https://access.redhat.com/solutions/1386833 https://www.redhat.com/en/blog/part-1-introduction-g1-garbage-collector