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

[Aleksey Shipilev]

On Thu, 18 Sep 2025 06:16:49 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> This adds another argument to something else we discussed yesterday, why is this initial value a fraction of the RAM and not a fraction of the chosen `MaxHeapSize`? We could not come up with a good answer to that, do you see any good reason?

Yeah, I also wondered about this, but I could not find any discussion why the heuristics is driven like this. So I am guessing it can be filed into a constantly growing "historical reasons" folder. It makes _some_ sense to drive Xms and Xmx separately, so that users who override only Xmx do not get an additional effect on Xms? I.e. so that GC would be in the same initial configuration when running experiments with different Xmx-es, for example. This is the only explanation I can come up with.

Anyway, changing the _way_ Xms is selected feels way too much work, given the benefits we are after. This PR does a simple thing of adjusting the already documented ergonomic input and requires no additional code changes on top of that. This is a soft touch that does a minor change to gain minor benefit for IMO non-frequent cases of users skipping any heap configuration. (Use case: showing startup numbers on conference slides :D). If there is a strong preference of overhauling Xms policy itself, it would be a while before I could allocate any reasonable cycles to it, and someone else would probably need to take over.

So, I believe we should do this trimming, since some init work is unavoidable, and then spend extra free time on actual improvements in GC initialization sequences that make startup faster in cases when users _do_ supply Xms :)

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

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