Why is it common practice to set -Xms equal to -Xmx on long-running server JVMs, and what is the argument against doing it?

## What the JVM does when the two differ The heap lives between an initial committed size (-Xms) and a maximum (-Xmx). After collections, HotSpot compares the proportion of free heap against -XX:MinHeapFreeRatio (default 40) and -XX:MaxHeapFreeRatio (default 70). Too little free and it expands by committing more of the reserved address range; too much free and it shrinks, returning pages to the operating system. G1 additionally uncommits at concurrent-cycle boundaries as well as at full collections, and -XX:-ShrinkHeapInSteps changes whether shrinking happens gradually or in one move. So a heap that is not pinned tracks demand. That sounds purely good, and on a laptop it is. ## Why servers pin them equal First, resizing is not free. Committing memory means the operating system must supply pages, and the first write to each page takes a fault; on a busy service that cost lands inside request latency. Shrinking then re-growing repeats it. Under load spikes - exactly when you care - the JVM is doing the most resizing. Second, resize decisions are entangled with collection. Heap expansion and, in the older collectors, most shrinking happen at collection boundaries, and heap-occupancy-driven heuristics such as when to start a concurrent cycle are computed against the current committed size. A heap that keeps changing size keeps moving those thresholds, so behaviour is less reproducible and tuning done at one size may not hold at another. Third, and most important operationally: predictability. With -Xms equal to -Xmx the process footprint is settled at startup. If that footprint does not fit the container, the service fails immediately and visibly. With a small -Xms it starts happily and grows into the limit hours later at peak traffic, where exceeding it means a kernel OOM kill of the whole process rather than a Java-level error. Pinning converts a latent production failure into a startup failure. Fourth, stability of layout. A stable committed heap gives collectors a stable region or generation layout; repeatedly returning and re-acquiring memory means re-establishing that structure and can leave the address space and the collector's bookkeeping in a less tidy state on a process that runs for weeks. Many teams pair the pinned heap with -XX:+AlwaysPreTouch, which writes to every heap page during startup so the pages are really backed before traffic arrives. This trades a longer, memory-hungry startup for the absence of first-touch faults later, and it makes the resident footprint honest immediately rather than creeping upward. ## The case against The strongest counter-argument is money and density. A pinned heap holds its full size whether or not the application needs it, so co-locating many services on one node, or running functions that idle most of the time, wastes real capacity. Modern collectors are markedly better at giving memory back - G1 uncommits during concurrent cycles, and ZGC and Shenandoah have explicit uncommit behaviour with idle delays - which makes elasticity a genuine option rather than a theoretical one. There are also environments where a large initial commitment is actively harmful: short-lived CLI or serverless invocations where startup time dominates, development machines, and platforms that bill on observed memory rather than on the declared limit. ## A defensible middle position Set -Xms to the size the service actually needs in steady state, measured as live set plus collection headroom, and -Xmx to that same value on a dedicated, long-running server. Where elasticity has real value, keep -Xms at the honest steady-state floor and allow -Xmx some room above it, accepting occasional resize cost in exchange for returning memory when idle. What you should not do is leave -Xms at a tiny default on a service that will certainly grow: you get all of the resize cost and all of the late-failure risk with none of the density benefit. Whichever you choose, the heap bounds must be justified against the whole process budget, since the heap is only part of what the container is charged for.