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

[Aleksey Shipilev]

On Wed, 17 Sep 2025 13:43:50 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> 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? 

Well, as I argued before, capping does not turn out to be simpler: https://github.com/openjdk/jdk/pull/23262#issuecomment-2701763566.

Performance-wise, "simpler" capping gives you surprises as well. It is easy to see there is a primary _linear_ effect with `Xms` for Serial, Parallel, G1: the larger the initial commit, proportionally more time is needed for initializing the heap itself and the internal structures that are usually linear to the size of the (initial) heap.

But for G1 specifically, there is a second-order _non-linear_ effect, which shows up on small heap configurations. With Xmx <= 2G, you can get really unlucky. See the graphs in [JDK-8348278](https://bugs.openjdk.org/browse/JDK-8348278). You can see there, for example, that configurations with <= 2G Xmx for G1 are the worst configurations, and they get worse as `Xms` comes closer to `Xmx`. Intuitively, this is due to some G1 configs have a lot of small-ish regions, which are pain to init, and larger `Xms` forces you to init more regions. (See also: [JDK-8348270](https://bugs.openjdk.org/browse/JDK-8348270)).

In other words, the reasonable-on-a-surface idea of capping at `Xms2g` turns out to be the worst default for a default collector, because it almost always does Xmx=Xms on a large-ish machine, like my desktop :) In other words, for G1, 2G Xms cap is way, way too high.

So you would want to cap `Xms` fairly low. Otherwise, if you leave `Xmx` to auto-selection too, you may end up stepping into G1 pain zone. (In fact, that is what happened to me in Leyden startup experiments! This is how I found this is a problem.) Trimming `IRAMP` is more convenient way to achieve this, because with it -- Xmx compressed oops caps notwithstanding -- Xms and Xmx would _both_ be ratio-ed from system memory size, and thus Xms would very likely be far away from Xmx, even if you are in pain zone. Plus, as I noted before, it piggybacks on already existing ergonomics infrastructure, which avoids extra work.

Bottom-line: On balance, trimming `IRAMP` is much easier way out.

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

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