Summary

Remove the default value of the MaxRAM flag so that it only has an effect if a user explicitly sets it; otherwise, ergonomic heap sizing will be based solely on physical memory reported by the operating system. Additionally, the MaxRAM flag should be deprecated in JDK 26, be obsoleted in JDK 27, and removed in JDK 28.

Problem

MaxRAM is used when ergonomically setting the heap size in cases where the heap size is not explicitly configured. By default, MaxRAM is set to 128GB on 64-bit systems, 4GB on 32-bit systems and 1GB in some cases.

If the user has not configured MaxRAM, MaxRAMPercentage, MinRAMPercentage or InitialRAMPercentage, ergonomic heap sizing will use the minimum of the reported physical memory by the OS and MaxRAM. If MaxRAM is not configured, but any of MaxRAMPercentage, MinRAMPercentage or InitialRAMPercentage are, then ergonomic heap sizing will use the reported physical memory by the OS. If MaxRAM is configured, ergonomic heap sizing will use that value.

The behavior of ignoring the default value of MaxRAM when any of MaxRAMPercentage, MinRAMPercentage or InitialRAMPercentage are set and MaxRAM is not set was added as a way to get around the default value of 128GB of MaxRAM. This raises the question if having a default value for MaxRAM is really necessary. Furthermore, we've seen that the seemingly arbitrary value of 128GB is unintuitive for users in the community.

The introduction of Automatic Heap Sizing (AHS) in collectors like ZGC, G1, Serial and Parallel emphasizes the need for a straightforward and predictable approach to heap sizing, where both the default value of and the MaxRAM flag itself are not clear if they are necessary any more.

Even without AHS, explicit configuration of MaxRAM is rarely necessary, as the JVM can accurately detect physical memory and consider commit limits. Also, setting MaxRAM above physical memory could lead to misconfiguration or incorrect sizing and, to our knowledge, is not a common use case. There might be niche scenarios, such as simulating heap sizing decisions for systems with more memory, which can typically be handled through other means in development or testing environments instead. Thus, keeping a default MaxRAM value offers little benefit and adds unnecessary complexity. To simplify ergonomic heap sizing and reduce confusion, the MaxRAM flag itself should be deprecated. Users who need to control the heap size directly are encouraged to use standard, well-supported flags such as -Xms and -Xmx instead.

Solution

The default value of MaxRAM should be removed and always use the size of the physical memory as reported by the OS, unless the user has explicitly set MaxRAM. Additionally, the MaxRAM flag is deprecated for removal in JDK 26, obsoleted in JDK 27 and removed in JDK 28.

Setting MaxRAM explicitly will continue to work as before until the flag is removed. The behavior of the MinRAMPercentage, MaxRAMPercentage or InitialRAMPercentage flags are unchanged.

Specification

Removing the default value of MaxRAM and only use the flag's value if the user explicitly sets it:

if (FLAG_IS_DEFAULT(MaxRAM)) {
  // If the user has not specified MaxRAM, use the size of the physical
  // memory reported by the OS.
  FLAG_SET_ERGO(MaxRAM, os::physical_memory());
}

// Otherwise use the value already in MaxRAM.

Deprecating the flag:

  product_pd(uint64_t, MaxRAM,                                              \
          "Real memory size (in bytes) used to set maximum heap size")      \
          range(0, 0XFFFFFFFFFFFFFFFF)                                      \