How do you optimise Java Virtual Machine (JVM) garbage collection to eliminate tail latency spikes in a game server?

Short answer

Analyse JVM tuning strategies to prevent Stop-The-World (STW) pauses and ensure predictable microsecond response times for game server logic.

Game servers executing a main physics and logic loop at a strict 60Hz have a computational budget of approximately 16.6 milliseconds per tick. While the average tick execution time might be healthy, tail latency spikes at the 99.9th percentile can easily exceed 150 milliseconds due to the Java Virtual Machine (JVM) Garbage Collector (GC). These spikes cause catastrophic Stop-The-World (STW) pauses that result in rubber-banding, broken simulation determinism, and disconnected players.

The mechanics of JVM memory management dictate that rapid creation of short-lived objects (such as temporary vectors for physics calculations or byte buffers for network transmission) aggressively fills the Thread Local Allocation Buffer (TLAB) within the Young Generation. When Eden fills up, a Minor GC triggers, pausing application threads to copy survivors. If the allocation rate outpaces collection, objects are prematurely promoted to the Old Generation, eventually forcing a massive Major GC that halts the server entirely.

flowchart TD
  A["Object Allocation (TLAB)"] --> B["Eden Space (Young Gen)"]
  B --> C{"Eden Full?"}
  C --> |"Yes"| D["Minor GC (Short STW Pause)"]
  D --> E["Survivor Space"]
  E --> F{"Survive Tenuring Threshold?"}
  F --> |"Yes"| G["Promote to Old Gen"]
  G --> H{"Old Gen Full?"}
  H --> |"Yes"| I["Major GC (Long STW Pause)"]

Flags cannot fix a hostile allocation pattern

The classic developer mistake is attempting to solve this purely through JVM flags, tweaking -XX:NewRatio or MaxGCPauseMillis on G1GC, hoping a magical configuration will bend the collector to their will. This is a losing battle. Tuning flags cannot defeat a fundamentally hostile allocation pattern. If the game loop is instantiating thousands of vector objects per tick, the GC will eventually fall behind, leading to allocation stalls. The trap is believing operations can solve a code-level architectural flaw.

Zero-allocation architecture

The only true defence is adopting aggressive zero-allocation programming patterns to relieve pressure on the GC entirely. Large pools of reusable objects must be pre-allocated during server initialisation. Instead of instantiating new mathematical vector objects during collision detection, existing objects are checked out from a thread-local pool, mutated, and returned.

String concatenations must be replaced with reusable StringBuilder instances, and primitive arrays (int[]) heavily favoured over boxed collections (ArrayList<Integer>). By drastically reducing the allocation rate, the time between Minor GCs is extended, and short-lived objects avoid premature promotion. Structuring code to leverage Escape Analysis and Scalar Replacement allows the JVM to allocate temporary primitives on the stack rather than the heap.

Concurrent collectors and safepoints

Once the allocation rate is mathematically restrained, modern low-latency garbage collectors like Z Garbage Collector (ZGC) or Shenandoah provide the final layer of defence. These collectors perform expensive work—root scanning, object relocation, and reference updating—concurrently with application threads, leveraging coloured pointers and load barriers to keep STW pauses under one millisecond.

However, even with ZGC, Time-To-Safepoint (TTSP) issues remain a threat. The JVM requires all threads to reach a safepoint before initiating a pause. Long, uncounted loops in physics engines can prevent a thread from reaching a safepoint quickly. Refactoring these loops to ensure safepoint polling is enabled guarantees rapid suspension. Finally, dedicating more CPU cores to concurrent garbage collection threads (-XX:ConcGCThreads) ensures the collector can keep pace with the game loop without robbing processing power from the actual game logic.

Achieving stable tickrates in managed languages requires a two-pronged approach: radically minimising object allocation through pooling, primitive data structures, and stack allocation to reduce garbage generation, and deploying concurrent garbage collectors tuned with adequate heap headroom and CPU resources to reclaim memory without halting the application execution.

© 2026 Preptima. Originally published at preptima.com.