The value of the MaxRAM flag is used when setting the heap size ergonomically when the user has not explicitly specified at least one of `-Xmx` (equivalent to `-XX:MaxHeapSize`), `-Xms`, `-XX:MinHeapSize` or `-XX:InitialHeapSize`.

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 explicitly 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.

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 `-Xmx` and `-Xms` instead.