What do the Java command-line options -Xms and -Xmx set, and what does the HotSpot JVM choose for them when you specify neither?

## The two bounds The Java heap is the region the garbage collector manages, holding all objects and arrays. Its size is bounded at both ends by command-line options that have kept their non-standard names for decades. -Xms sets the initial heap: the amount the JVM reserves and commits at startup. In practice it also acts as a floor, because HotSpot will not shrink the committed heap below it. -Xmx sets the maximum: the ceiling beyond which the heap will not grow. Both accept suffixes, so -Xms512m and -Xmx4g are typical spellings. Newer equivalents express the same thing as fractions of available memory: -XX:InitialRAMPercentage and -XX:MaxRAMPercentage, which are the better choice in containers because they scale when the limit changes. ## Growth and shrinkage between them When a collection ends and too little of the heap is free, the JVM commits more memory, up to -Xmx. When far too much is free, it may return memory, down to -Xms. HotSpot's classic controls for this are -XX:MinHeapFreeRatio and -XX:MaxHeapFreeRatio (40 and 70 by default in the collectors that use them): keep free space between those percentages after a collection, expanding or shrinking to get there. It is worth separating two words. Reserved memory is address space the JVM claimed up front, typically the whole of -Xmx. Committed memory is what is actually backed by the operating system and counts toward the process footprint. Growing the heap means committing more of the already-reserved range. ## The defaults If you pass neither flag, HotSpot chooses using its ergonomics. On a server-class machine the rule of thumb is initial about 1/64 of available memory and maximum about 1/4, with small-memory adjustments at the low end. The important modern detail is what 'available memory' means: since JDK 10 the JVM is container-aware by default (-XX:+UseContainerSupport), so inside a container with a memory limit it reads the cgroup limit rather than the host's physical RAM. Before that, a JVM in a 512 MB container on a 64 GB host would happily size its heap for 64 GB and be killed by the kernel. A default maximum of 25% is deliberately conservative and is usually wrong for a dedicated service container, where three quarters of the memory you paid for would sit unused. Setting -XX:MaxRAMPercentage explicitly - or a fixed -Xmx - is the normal production practice. ## What these flags do not cover A very common misunderstanding is that -Xmx caps the memory of the Java process. It does not. Outside the heap the process also holds class metadata in metaspace, JIT-compiled code in the code cache, one stack per thread, direct and mapped byte buffers, garbage-collector bookkeeping structures, and whatever native libraries allocate. A process with -Xmx1g routinely uses well over 1.3 GB of resident memory. Any memory budget - a container limit, a capacity plan - has to account for all of it. ## When the ceiling is reached If the application's reachable data cannot fit under -Xmx, the collector will run repeatedly, reclaim little, and eventually the JVM reports OutOfMemoryError for the heap. Raising -Xmx is the right response only when the live set is legitimately that large; otherwise it postpones the same failure. Note also that the JVM refuses to start if -Xms exceeds -Xmx, and that an -Xms larger than the machine or container can supply fails at startup rather than later. ## Practical starting point For a dedicated container, decide the total budget, subtract a realistic non-heap allowance, and set the heap explicitly - either as a fixed -Xmx or as a percentage - rather than relying on a 25% default that was chosen for shared desktop machines.