Summary

This change proposes to eliminate the default value of InitialRAMPercentage, which influences how InitialHeapSize is determined. Instead, InitialHeapSize will always default to the value of MinHeapSize, the lowest permissible heap initialization value, unless overridden by user configuration.

Problem

Historically, the default value for InitialRAMPercentage was 1/64 of the available system memory, capped at 1/64 of 128GB. With JDK-8348278, this percentage was reduced to 1/512 to boost startup performance by shrinking initial heap allocation. As a result, the InitialRAMPercentage calculation became capped at 1/512 of 128GB instead. Previous changes in JDK-8369346 removed the default value for and deprecated the MaxRAM flag to simplify reasoning about ergonomic heap size selection. As a result, the previous cap of 1/512 of 128GB no longer applies, and the calculation is now based solely on the actual system memory size. However, the fixed-percentage approach of InitialRAMPercentage leads to non-intuitive and error-prone behavior:

• Inconsistency Across Environments: The current approach causes InitialHeapSize to vary dramatically based on total system memory rather than user-specified limits, leading to initial heap sizes as large as 4GB on a 2TB machine but only 128MB on a 64GB machine, regardless of -Xmx setting. This results in unpredictable and sometimes suboptimal behavior that doesn't consistently align with user intent.
• Interaction With Other Flags: When either the default or a user-supplied value for InitialRAMPercentage causes InitialHeapSize to exceed MaxHeapSize, InitialHeapSize is automatically capped at MaxHeapSize. This behavior is subtle, as the ergonomics will effectively ignore the value for InitialHeapSize if it exceeds MaxHeapSize, always enforcing the maximum heap limit. This is especially confusing for users who configure such a value manually.
• Complexity & Opacity: The interaction of InitialRAMPercentage, InitialHeapSize, MinHeapSize, and MaxHeapSize creates a system that is hard for users to reason about, making memory tuning unnecessarily opaque and introducing potential for subtle bugs.

Solution

Defaulting InitialHeapSize to MinHeapSize brings several advantages. Most importantly, it provides simplicity and predictability, ensuring users can easily understand the default behavior of the InitialRAMPercentage flag. This step aligns closely with existing JVM ergonomics, since specifying -Xms already sets both MinHeapSize and InitialHeapSize, making their connection explicit, intuitive, and consistent for users.

It is important to emphasize that selecting a default value for InitialRAMPercentage fundamentally involves a trade-off between startup and runtime performance. A larger initial heap size grants the GC more headroom initially, potentially reducing early GC cycles and resizing events. In contrast, a smaller initial heap can result in more GC activity and resizing as the heap fills up and adjusts to demand at runtime. However, it is extremely challenging to pick a single numeric default that suits the needs of most applications, given their diversity. Therefore, we propose to always choose the minimum possible initial heap size, as this consistently optimizes for startup performance. For users more concerned with runtime performance than startup, they are always able to explicitly configure the InitialHeapSize via one of -Xms, -XX:InitialHeapSize, or -XX:InitialRAMPercentage to meet their requirements.

By making this the default behavior, we effectively remove opaque GC heuristics and provide a consistent, predictable starting point that is easy to understand and reason about. If the user hasn't specified their preferences, we optimize for what can be objectively beneficial, faster startup, while allowing users to tune for other needs as appropriate.

From a performance perspective, minimizing the initial heap size leads to faster startup, as targeted by JDK-8353837. Adaptive heap growth ensures that additional memory requirements can still be met efficiently as the application runs. We share the same concerns and observations highlighted in JDK-8353837: depending on the heap sizing policy of the chosen garbage collector, reducing the initial heap may trigger more frequent resizings until a stable heap size is reached. However, this behavior is generally not an issue for small, out-of-the-box applications. For long-running or production workloads, the impact is expected to be minimal since most memory-conscious applications already set -Xms explicitly, which overrides the InitialRAMPercentage setting. This approach aligns with current usage patterns, making the default InitialRAMPercentage largely redundant and occasionally confusing. By directly tying the initial heap allocation to MinHeapSize, we prevent non-intuitive scaling based on host memory size, leading to more consistent and predictable behavior across a wide range of environments.

Solution Summary

Removing the default value for InitialRAMPercentage and defaulting InitialHeapSize to MinHeapSize makes the JVM's startup memory behavior simpler, more predictable, and startup-performance-friendly. It avoids legacy quirks and aligns with best practices, giving users clearer expectations and greater control over application memory usage. This change only affects the default behavior in the absence of explicit user setting of InitialRAMPercentage.

Specification

  product(double, InitialRAMPercentage, 0,                                  \
          "Percentage of real memory used for initial heap size")           \
          range(0.0, 100.0)                                                 \