This Stack Overflow answer is pretty decent: https://stackoverflow.com/a/23284897

I think basically the argument is that by setting the min bound lower, you allow the JVM to shrink the heap. This could maybe be beneficial towards reducing pause time because the JVM has less memory to manage overall. That being said, that SO answer also mentions:

> Sometimes this behavior doesn't give you the performance benefits you'd expect and in those cases it's best to set mx == ms.

I've also seen apps configured this way professionally for similar reasons. You might imagine some app that leads to the JVM pathologically trimming the heap in a way that isn't desirable and thus impacts performance in some subtle way, etc. The answer with a lot of this stuff is usually try both ways, measure, see if you can observe a meaningful difference for your apps/workload for typical/peak traffic.

Background: I've worked on Java apps for a few years at reasonable scale and worked on GC pressure issues in that time.

If you run it in a container the best advice it to leave things with default options. JVM has ergonomic GC options and with adaptive heap sizing. 95% of time you dont need to change anything at all.

where to start... first the other commenter is correct. If you need to run to the connivence store that's 250 yards away, what is more efficient? Firing up a 7,100hp Union Pacific Diesel locomotive and plowing through everything/everyone to get there, or taking a electric scooter? A smaller heap means less to scan, meaning less work, meaning lower latency. Now G1GC removes some of this penalty due to its algorithm, but in general, less memory is less memory scanned, meaning better best-case performance from a GC. Let that Adaptive GC Boundary do it's thing.

and now, rant time: well, Xms allegedly improves start times. Is that really important? No. Is that really true anyway? Not really. Xms hides problems... Yes. Give that memory to the OS. Let it fill it up with things like disk cache or COW artifacts. Xms is an attempt to help people that aren't planning properly or testing. Yes. Instead, Test your systems under full load with Xms off and adjust, measure, experiment, repeat.

Elastic is sort of a special case because it's a 'database', but, I'd rather know the minimum Xmx my system actually needs by experimentation, and you can't find that with Xms enabled. And even then, I don't see MySQL allocating 100% of its InnoDb bufferpools at startup.... :)

honestly none of these sound like compelling reasons to not just set -Xms to Xmx

You scan the live set (which most often is not dependent on the heap size). Bigger heap most often means better performance. Setting Xms to Xmx is good and valid if you know how much memory you need (which often is the case).

  If you prefer high throughput, then relax the pause-time goal by using -XX:MaxGCPauseMillis or provide a larger heap. If latency is the main requirement, then modify the pause-time target. Avoid limiting the young generation size to particular values by using options like -Xmn, -XX:NewRatio and others because the young generation size is the main means for G1 to allow it to meet the pause-time. Setting the young generation size to a single value overrides and practically disables pause-time control. [1]

  Setting -Xms and -Xmx to the same value increases predictability by removing the most important sizing decision from the virtual machine. However, the virtual machine is then unable to compensate if you make a poor choice. [1]

[1] https://docs.oracle.com/en/java/javase/19/gctuning/introduct...

> However, the virtual machine is then unable to compensate if you make a poor choice.

> Test your systems under full load with Xms off and adjust, measure, experiment, repeat.

precisely what I'm saying.

>>You scan the live set (which most often is not dependent on the heap size).

This was an eye-opener for me; That GCs performance do not depend on the size of garbage but on the size of the live objects, finalizers excluded.