Why do I get GC more often when I raise memory?

The JVM set up with G1GC will be started by constructing a memory block called region without any distinction of New / Survivor / Old physical memory. Logically there is New / Survivor / Old, but it is not physically separated by address.

The objects are created in any region, and the referrer information of the object is stored in a Remember set (using 5% level in the whole Heap). The remember set is a data structure that makes it easy to know which region is assigned an object with reference. (track references into the region)

If an object that is larger than the region size is to be created, it will create an Object over several regions, and this set of regions is called Humongous. This information is also stored in the remember set.

The region sizes can vary from 1 MB to 32 MB depending on the heap size. The following table shows the region size that will be chosen based on the minimum heap size should the region size not be explicitly set.

|---------------------|------------------|
|    Min Heap Size    |   Region Size    |
|---------------------|------------------|
|     heap < 4GB      |       1MB        |
|---------------------|------------------|
|  4GB <= heap < 8GB  |       2MB        |
|---------------------|------------------|
|  8GB <= heap < 16GB |       4MB        |
|---------------------|------------------|
| 16GB <= heap < 32GB |       8MB        |
|---------------------|------------------|
| 32GB <= heap < 64GB |      16MB        |
|---------------------|------------------|
|     64GB < heap     |      32MB        |
|---------------------|------------------|

So, in your case, the size of the region will be calculated differently. Also, the memory allocation pattern can vary depending on your application. To find a more accurate cause, we need a garbage collection log.

You can set InitiatingheapOccupancyPercent to let background threads start time. The ratio of heap usage to the total heap size. Decreasing the value allows you to start a background thread quickly. The default value is 45. However, if the value is too small, the garbage collection will run too often. It takes CPU cycles and may affect application performance itself.

As you know, The chainsaw graphs are healthy applications. Therefore, there is no big problem even if you do not do additional setting.


EXTRA: Bug reports that can help you troubleshoot issues

The description in Bug-8151176 refers to calculating the old gen occupancy/total heap size for the purpose of actually calculating IHOP

This means that the occupation of the young generation is completely ignored. That is, if the younger generation's fraction is greater than the IHOP, the concurrent cycle cannot start.

The reason is that static IHOP starts if old gen occupancy exceeds a fixed percentage of the current heap capacity. If either the user or ergonomics decide that the old gen cannot be larger than that fraction of the heap capacity that triggers concurrent mark, marking will never start.