Introduction

Ever wondered how g1 decide which regions should be included in the collection set, when to trigger the concurrent marking cycle, or why stops mixed gc?  You can get that information from -XX:+PrintAdaptiveSizePolicy

The Parameters:

In addition to the basic parameters -XX:+PrintGCTimeStamps -XX:+PrintGCDetails mentioned in previous blog how to print and how to understand - basic, add -XX:+PrintAdaptiveSizePolicy

The Outputs:

The output from basic gc details is skipped here. Please refer to blog how to print and how to understand - basic.

Young GC

Here I posted the Ergonomic output for a young gc. At the end of this gc, g1 requests the concurrent marking cycle.

After the marking cycles are done, sometimes, young gc has a line like this:

Mixed GC

Mixed gc has additional information about how old regions are included in the CSet

Thresholds and Parameters:

We mentioned a lot of thresholds. Here we will explain what those thresholds are and how to control them.  The numbers in <> is the default value.

• -XX:MaxGCPauseMillis=<200>
In the gc log, we saw some entries like: "target pause time: 100.00 ms". This is controlled by MaxGCPauseMillis.  This is a very important parameter as g1 adjusts heap generations sizes to meet this goal.
• -XX:G1NewSizePercent=<5>  -XX:G1MaxNewSizePercent=<60>
Sometimes we see that g1 does not push Eden size low enough to meet the gc pause goal, or does not have big Eden though still below the pause time goal. Please check if these 2 parameters are limiting the range of Eden that g1 can control ergonomically. G1NewSizePercent defines minimum percentage young gen over the heap size. G1MaxNewSizePercent defines maximum percentage young gen over the heap size.
• -XX:InitiatingHeapOccupancyPercent=<45>
This parameter defines when g1 initiate marking phase. In the gc log
136.332: [G1Ergonomics (Concurrent Cycles) request concurrent cycle initiation, reason: occupancy higher than threshold, occupancy: 48586817536 bytes, allocation request: 0 bytes, threshold: 48318382080 bytes (45.00 %), source: end of GC]
The threshold 48318382080 bytes is 45% of the heap size. Specifying this number too much lower under the live data set might waste the marking work.
• -XX:G1HeapWastePercent=<10>
G1 decides starting/continue mixed gc based on allowed wasted. This parameter indicates if the reclaimable heap is below this percentage, g1 will stop collecting. You can see this threshold in gc log

253.028: [G1Ergonomics (Mixed GCs) continue mixed GCs, reason: candidate old regions available, candidate old regions: 435 regions, reclaimable: 12312176992 bytes (11.47 %), threshold: 10.00 %]

252.240: [G1Ergonomics (Mixed GCs) start mixed GCs, reason: candidate old regions available, candidate old regions: 498 regions, reclaimable: 14269425416 bytes (13.29 %), threshold: 10.00 %]

• -XX:G1MixedGCCountTarget=<8> -XX:+UnlockExperimentalJVMOptions -XX:G1OldCSetRegionThresholdPercent=<10>
Under the mixed gc log, there is this log:

252.374: [G1Ergonomics (CSet Construction) added expensive regions to CSet, reason: old CSet region num not reached min, old: 63 regions, expensive: 63 regions, min: 63 regions, remaining time: 0.00 ms

The total number of candicate regions devided by the G1MixedGCCountTarget is the minimum old regions added to CSet.

Some times we see message like "old CSet region num reached max". G1OldCSetRegionThresholdPercent defines the percentage of the heap as the maximum number of old regions can be added to CSet.

• -XX:+UnlockExperimentalJVMOptions -XX:G1MixedGCLiveThresholdPercent=<65>
We do not see this reflected in the gc log, but some times this could be important, when the heap is tight. This means if a region's live data is above this percentage, g1 will not consider it as a candidate for mixed gc. If the heap is tight, you can try to increase it. However, since there are more live data, collecting this region can be more expensive.