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

[Stefan Johansson]

On Tue, 2 Sep 2025 12:57:47 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 two additional commits since the last revision:
> 
>  - Also man page
>  - Fix

Testing looks ok, we do see some regression in some micro-benchmarks. Likely because of smaller initial heaps. Not a very big deal, but there have been some internal discussions around changing the percentage versus capping the initial heap size to some "reasonable value", maybe 2G or so. 

There are pros and cons with both, but most people feel like there is less risk with capping the value. This will allow most deployments to not see a change, but for really large machines we won't use as much memory for the initial heap. I know this was brought up earlier as well, but still wanted to provide this feedback and hear if you have any more argument against capping? We cap the max heap size to the COOPs limit, so this would not be the first cap.

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

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