RFR: 8348278: Trim InitialRAMPercentage to improve startup in default modes [v2]

[Aleksey Shipilev]

On Wed, 5 Mar 2025 18:32:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See bug for discussion. This is the code change, which is simple. What is not simple is deciding what the new value should be. The change would probably require CSR, which I can file after we agree on the value.
>> 
>> I think cutting to 0.2% of RAM size gets us into good sweet spot:
>>  - On huge 1024G machine, this yields 2G initial heap
>>  - On reasonably sized 128G machine, this gives 256M initial heap
>>  - On smaller 1G container, this gives 2M initial heap
>> 
>> Additional testing:
>>  - [x] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Also man page
>  - Merge branch 'master' into JDK-8348278-trim-iramp
>  - Fix

I played with caps on reasonable initial heap size:


diff --git a/src/hotspot/share/gc/shared/gc_globals.hpp b/src/hotspot/share/gc/shared/gc_globals.hpp
index 924c45f137d..fd4d5fab5d7 100644
--- a/src/hotspot/share/gc/shared/gc_globals.hpp
+++ b/src/hotspot/share/gc/shared/gc_globals.hpp
@@ -292,6 +292,12 @@
           "Percentage of real memory used for initial heap size")           \
           range(0.0, 100.0)                                                 \
                                                                             \
+  product(size_t, InitialRAMMin, 8*M,                                       \
+          "Min initial heap size chosen using InitialRAMPercentage")        \
+                                                                            \
+  product(size_t, InitialRAMMax, 1024*M,                                    \
+          "Max initial heap size chosen using InitialRAMPercentage")        \
+                                                                            \
   product(int, ActiveProcessorCount, -1,                                    \
           "Specify the CPU count the VM should use and report as active")   \
                                                                             \
diff --git a/src/hotspot/share/runtime/arguments.cpp b/src/hotspot/share/runtime/arguments.cpp
index c6651c46e02..35d096f03d2 100644
--- a/src/hotspot/share/runtime/arguments.cpp
+++ b/src/hotspot/share/runtime/arguments.cpp
@@ -1592,6 +1592,8 @@ void Arguments::set_heap_size() {
 
     if (InitialHeapSize == 0) {
       julong reasonable_initial = (julong)(((double)phys_mem * InitialRAMPercentage) / 100);
+      reasonable_initial = MAX2<julong>(reasonable_initial, InitialRAMMin);
+      reasonable_initial = MIN2<julong>(reasonable_initial, InitialRAMMax);
       reasonable_initial = limit_heap_by_allocatable_memory(reasonable_initial);
 
       reasonable_initial = MAX3(reasonable_initial, reasonable_minimum, (julong)MinHeapSize);


...and the more I think about it, the less great it feels. To step back a bit:

We initially (pun intended) wanted to trim IRAMP to cater for out of the box use cases. Most production environments I saw set up `-Xms`, explicitly setting the initial heap size. So whatever we do here is covering effectively a corner case, and so the solution should likely balance the complexity against that goal. Adding two more flags maybe passes the bar, but it still increases maintenance burden: we would need to document these tunables, do sanity checks for them, write tests, etc. The heap sizing heuristics is already quite complicated (it other places), so there is a cognitive complexity to consider here as well.

Additional twist comes from obvious follow-up question: do we only apply these limits when user did _not_ override IRAMP, i.e. only in fully out-of-the-box mode? Or do we do this unconditionally (like in the patch above), so one can still override the auto-adjustable set-point within the limits? As a prospective user, I can reasonably argue both ways. This tells me this is another one of those snowballing complexity issues.

Current IRAMP is not great because machines got larger over the years. Choosing a new heuristics in a future-proof manner is not easy. Even if we introduce two more tunables, we would still need to figure out what are the future-proof values for them. It is a guess without knowing the characteristics of "reasonable" hardware that does not really exist yet.

So I would prefer to just trim a single tunable default to match current reality better, and move on. We can select a new value in ten years.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23262#issuecomment-2701763566