VM Runtime Tuning

On JDK 9 and later the default is G1 on any server-class machine (roughly two or more CPUs and enough memory). On a smaller machine or container, JVM ergonomics falls back to Serial. On JDK 8 the default was the Parallel collector.

-Xms is the initial heap size the JVM commits at startup; -Xmx is the maximum it may grow to. With neither set, HotSpot defaults to roughly 1/64 of available memory for initial and 1/4 for maximum, reading the container limit rather than host RAM when running under one.

Use the unified logging flag -Xlog. Its four colon-separated parts are selectors, output, decorators, output options: -Xlog:gc*:file=gc.log:time,uptime,level,tags:filecount=10,filesize=20M. It replaced -XX:+PrintGCDetails and -Xloggc, and is cheap enough to leave on in production.

Young collections log Pause Young, G1's mixed ones Pause Young (Mixed) (young plus some old regions), and full ones Pause Full, which collects and compacts the whole heap in one long stop. Under G1 or a concurrent collector, a Full GC signals the concurrent machinery failed to keep up.

Choose Parallel when total work per unit time matters and pauses do not — batch jobs, ETL, offline analytics, benchmarks. It usually delivers a few percent more throughput because it does no concurrent work and no write barriers. You give up pause control: its collections stop everything for a time that scales with the heap.

A bigger young generation fills more slowly, so minor collections happen less often. Each collection copies only the survivors, so its pause tracks surviving data, not eden size. Because most objects die fast, a bigger young space usually means fewer collections and fewer survivors per collection.

Pinning them equal stops the JVM repeatedly committing and releasing memory, which costs collection work and page faults, and it makes the process footprint predictable so the peak cannot surprise a container limit later. Against it: you pay for memory you may never use, and elastic services lose the ability to give it back.

Sort collections by duration, then read the outliers' lines: their scope and cause, whether To-space exhausted or a Full GC preceded them, the phase breakdown from gc+phases, the gc+cpu User/Sys/Real split, and safepoint timings. Cause first, then flags.

Choose them when a strict tail-latency SLO must hold on a large heap — pauses stay sub-millisecond to low-millisecond largely independent of heap size, because marking and relocation run concurrently. You pay barrier overhead on application code, extra CPU for concurrent work, and more heap headroom.

The container limit covers the whole process, not just the heap. Set the maximum heap to a fraction of the limit - commonly 50-75% depending on thread count and off-heap use - leaving room for metaspace, code cache, stacks, direct buffers and GC structures, then verify the real resident footprint with Native Memory Tracking.

It is a soft goal, not a guarantee. G1 uses it to size each collection set: to hit a smaller target it collects less per pause, so pauses become shorter but more frequent, throughput drops, and old-generation reclamation can fall behind. An unrealistic 5 ms mostly costs throughput without delivering 5 ms.

The young generation is eden plus two equal survivor spaces; only one survivor holds data at a time. -XX:SurvivorRatio=N makes eden N times one survivor. If the surviving objects do not fit in the target survivor space, they are promoted to the old generation immediately, regardless of age.

Below roughly 32 GB, HotSpot stores object references as 32-bit compressed pointers. Above that threshold it must use full 64-bit references, so every object with references grows and the whole live set expands - typically enough to swallow the extra 2 GB and more.

Allocation rate = (heap used before a collection − heap used after the previous one) ÷ the interval between them, averaged over many collections. Promotion rate = old-generation growth per collection ÷ the same interval. High allocation means frequent young pauses; high promotion means old-generation pressure and eventual long collections.

Metaspace and compressed class space, the JIT code cache, one stack per thread, direct and mapped byte buffers, garbage-collector bookkeeping, and native library allocations. Bound them with -XX:MaxMetaspaceSize, -XX:ReservedCodeCacheSize, -Xss plus bounded thread pools, and -XX:MaxDirectMemorySize; measure the rest with Native Memory Tracking.

Classify each service by its governing metric — tail latency, throughput, or footprint — then map: latency SLO plus a large heap goes to a concurrent collector, batch to a throughput collector, everything else to the pause-targeting default. Validate by running the real workload under load with GC logging and comparing pause percentiles, throughput and CPU.

Epsilon allocates and never collects; when the heap is exhausted the JVM exits with an OutOfMemoryError. It exists for performance testing where GC must be excluded, for measuring an application's true allocation footprint, for last-drop latency experiments, and for very short-lived processes that finish before the heap fills.

Rarely. Pinning the young size with -Xmn disables the adaptive sizing that serves the pause goal, so the collector can no longer trade young size for latency as the workload shifts. Justify it only for throughput-only batch work, benchmarking reproducibility, or when adaptation demonstrably misbehaves - and prefer raising the floor instead.