Summary

Change the default values for MinHeapFreeRatio and MaxHeapFreeRatio flags when using the Garbage-First (G1) garbage collector. Their new values will not affect Java heap sizing any more unless explicitly set by the user.

Problem

The Java virtual machine (VM) provides the manageable MinHeapFreeRatio and MaxHeapFreeRatio options that make the G1 garbage collector keep a minimum and maximum percentage of free Java heap memory committed after whole heap garbage collections (Full GCs).

These options are problematic regarding both efficient memory use and application performance:

• The current default values of 40 and 70 percent for MinHeapFreeRatio and MaxHeapFreeRatio respectively are too conservative in many situations.

  For example, keeping 40% of free Java heap memory around has a different system impact on Java heaps in the GB range than for Java heaps in the hundreds of MB. Particularly because for large Java heaps, depending on application behavior that 40% of required free memory may be wasted if it is not necessary to keep performance goals. Similarly, keeping up to 70% of free Java heap around before giving memory beyond that back to the environment can be similarly wasteful.

• This free memory reserve overrides G1's ergonomic application based behavior based Java heap sizing heuristics, which leads to unexpected and undesirable behavior for users who do not use a fixed Java heap size in presence of Full GCs.

  For example, if the application explicitly issues a System.gc() call at well known places in the application where there is little live data in the Java heap, observing MaxHeapFreeRatio may result in aggressive heap shrinking, that will be undone over time as G1 ergonomics responds to subsequent application activity. Until the Java heap grows to to an adequate size, the application may run at a significantly reduced performance. The effect is the same for Full GCs caused by other policies.

  The reverse can be true as well: Full GCs increase the Java heap size due to observance of MinHeapFreeRatio beyond what G1 requires for operation, only to be reverted during subsequent garbage collections because application behavior indicates that that extra free memory is not required to meet performance goals. While G1 adapts to application behavior, the VM will hold on to much more than necessary memory.

  Overall, these forced oscillations in Java heap size cause unnecessary heap resizing activity, leading to performance drops. This includes not only the immediate impact like memory allocation requests to the environment, but also non-immediate impact to throughput by G1 ergonomics slowly re-adjusting the Java heap to optimal size, or the VM holding on to unnecessary memory.

Solution

Change the default values for MinHeapFreeRatio and MaxHeapFreeRatio in G1 so that they do not affect heap resizing decisions. Heap resizing driven by these flags will occur only if the user explicitly sets them.

This also corresponds to the default behavior of the Parallel collector.

This results in that G1 heap sizing will be, by default, determined solely by G1's ergonomic policies based on application behavior. Explicitly setting the flags to the original values either at the command line or programmatically at runtime preserves the existing behavior, ensuring backward compatibility for users who intentionally rely on these options in some situations.

Specification

https://github.com/openjdk/jdk/pull/29137

 +  if (FLAG_IS_DEFAULT(MinHeapFreeRatio)) {
 +    FLAG_SET_DEFAULT(MinHeapFreeRatio, 0);
 +  }
 +  if (FLAG_IS_DEFAULT(MaxHeapFreeRatio)) {
 +    FLAG_SET_DEFAULT(MaxHeapFreeRatio, 100);
 +  }