Garbage Collection Java

Introduction

When a Java program runs, it lives inside a virtual world that is both powerful and fragile. The Java Virtual Machine (JVM) gives developers a safety net: objects are allocated with a simple new expression, and the runtime promises to clean up memory that is no longer reachable. That promise is fulfilled by garbage collection (GC), a sophisticated set of algorithms that constantly shuffle, compact, and reclaim memory while the application is serving requests, processing data, or even idle.

For developers building latency‑sensitive services—real‑time analytics, high‑frequency trading platforms, or AI agents that must respond within milliseconds—GC is not just a background task; it is a performance frontier. A pause of 200 ms can break a user experience, a 5 ms hiccup can cause a missed trading opportunity, and an uncontrolled heap growth can crash a node and cascade failures across a distributed system.

At Apiary, we draw inspiration from the natural world: a bee colony thrives because each generation of workers knows when to stay, when to leave, and how to allocate resources efficiently. Similarly, a JVM’s generational GC strives to keep “young” objects short‑lived while promoting long‑lived data to a safe haven. Understanding the mechanics behind that process, the knobs we can turn, and the impact on latency is essential not only for Java engineers but also for anyone designing self‑governing AI agents that must manage their own memory footprints responsibly—just as a bee colony regulates its brood.

This article dives deep into the JVM’s generational GC algorithms, the most relevant tuning flags, and the concrete ways they affect latency. We’ll walk through the theory, the practical tools, and a real‑world tuning case study, all while keeping an eye on the broader lessons for conservation‑focused AI systems.

1. The Building Blocks of Java Memory

Before we can discuss how GC works, we need a clear picture of where it works. The JVM divides memory into several logical regions, each with a distinct purpose:

The heap is the centerpiece of GC. Most modern JVMs adopt a generational layout: a young generation (further divided into Eden and two Survivor spaces) and an old generation (also called Tenured). The young generation typically occupies 1/4 to 1/3 of the total heap, but this ratio can be tuned with -XX:NewRatio or -XX:NewSize flags.

Why Generations?

Empirical studies of Java workloads (e.g., the DaCapo benchmark suite) show that ≈85 % of objects die within the first few milliseconds after allocation. This “infant mortality” pattern is called the generational hypothesis. By focusing collection effort on the young generation, the JVM can reclaim most garbage quickly and with minimal copying overhead. Objects that survive several young‑gen collections are promoted to the old generation, where they are collected less frequently but with more thorough algorithms.

2. The Generational Hypothesis in Detail

2.1 Young Generation Mechanics

When a thread allocates an object, the JVM places it in Eden. When Eden fills up, a minor GC (also called a young collection) is triggered:

1. Mark Phase – The JVM scans root references (stack frames, static fields, JNI handles) and marks all reachable objects in Eden and the two Survivor spaces (S0 and S1).
2. Copy Phase – Live objects are copied to the to‑space Survivor (e.g., from S0 to S1). Objects that have survived a configurable number of minor GCs (-XX:MaxTenuringThreshold, default 15) are promoted to the old generation.
3. Sweep Phase – The now‑empty Eden and the from‑space Survivor are reclaimed in bulk, a very cheap operation.

Because copying is done in a contiguous fashion, allocation in Eden is essentially a pointer bump—an O(1) operation. Minor GCs typically take 1–10 ms on a modern server with a 4 GiB heap, far shorter than full GC pauses.

2.2 Old Generation Mechanics

The old generation holds objects that have demonstrated longevity: cached data structures, thread pools, parsed configuration objects, etc. Collection here is more expensive because it often involves mark‑compact or mark‑sweep phases that must traverse a larger graph.

Key parameters:

The old generation is where latency problems usually surface. A poorly tuned old‑gen collector can cause stop‑the‑world (STW) pauses that exceed 500 ms, especially under heavy allocation pressure.

3. Major GC Algorithms in the HotSpot JVM

The HotSpot JVM (the reference implementation used by OpenJDK, Oracle JDK, and most vendors) ships with several collectors, each optimized for different workloads. Below we outline the most relevant ones for latency‑sensitive applications.

3.1 Serial GC (-XX:+UseSerialGC)

• Algorithm: Single-threaded mark‑compact for both young and old generations.
• Best For: Small heaps (≤ 2 GiB), single‑core machines, batch jobs where throughput matters more than latency.
• Pause Times: Minor GC ~ 1 ms, Full GC can reach 200 ms on a 2 GiB heap.
• Memory Footprint: Minimal; no extra thread stacks.

3.2 Parallel GC (-XX:+UseParallelGC)

• Algorithm: Multi‑threaded throughput‑oriented collector; uses multiple worker threads for both minor and major collections.
• Best For: Compute‑heavy services where GC overhead must be amortized over many cores.
• Pause Times: Minor GC 5–15 ms on a 8‑core machine; Full GC 300–600 ms.
• Tuning: -XX:ParallelGCThreads controls the number of GC worker threads (default = number of logical CPUs).

3.3 CMS (Concurrent Mark‑Sweep) (-XX:+UseConcMarkSweepGC)

• Algorithm: Concurrent phases for marking and sweeping old generation; only the initial mark and remark phases pause the application.
• Best For: Low‑latency services that can tolerate higher CPU usage.
• Pause Times: Typically 20–100 ms for old‑gen phases; minor GC still stops the world.
• Drawbacks: Susceptible to concurrent mode failure when allocation rate exceeds reclamation rate, leading to a full stop‑the‑world fallback.
• Deprecation: Removed in JDK 15; superseded by G1.

3.4 G1 GC (-XX:+UseG1GC)

• Algorithm: The heap is divided into regions (default 2 MiB each). G1 performs incremental evacuation of a subset of regions to meet a pause‑time target (-XX:MaxGCPauseMillis).
• Best For: Applications with large heaps (4 GiB–32 GiB) that require predictable pause times.
• Pause Times: Typically 10–200 ms, configurable.
• Key Metrics:
• Eden and Survivor regions are collected like a minor GC.
• Mixed collections combine young and old regions.
• Tuning Flags:
• -XX:InitiatingHeapOccupancyPercent (default 45) – when to start a concurrent cycle.
• -XX:G1HeapRegionSize – region size (1 MiB–32 MiB).

3.5 ZGC (-XX:+UseZGC)

• Algorithm: Region‑based, mostly concurrent collector introduced in JDK 11. Performs all phases (mark, relocate, reclaim) concurrently; only a tiny stop‑the‑world pause of ≤ 10 ms is needed for thread‑stack scanning.
• Best For: Ultra‑large heaps (≥ 8 GiB) with stringent latency requirements (e.g., in‑memory databases, AI model serving).
• Pause Times: 1–10 ms, independent of heap size.
• Memory Overhead: ~ 6 % of heap for load‑balancing structures.
• Tuning: Very few knobs; -XX:ZCollectionInterval can control the frequency of concurrent cycles.

3.6 Shenandoah (-XX:+UseShenandoahGC)

• Algorithm: Similar to ZGC, but uses brooks‑pointer technique for object relocation, enabling concurrent compaction.
• Best For: Latency‑critical workloads on OpenJDK builds that ship Shenandoah (e.g., Red Hat).
• Pause Times: 1–10 ms, comparable to ZGC.
• Tuning: -XX:ShenandoahThreshold controls when to start a concurrent cycle (default 30 % heap occupancy).

3.7 Choosing the Right Collector

4. Tuning Flags: From Basics to Advanced

Even with the right collector, mis‑configured heap sizes or thresholds can sabotage latency guarantees. Below we present a pragmatic checklist of the most impactful flags.

4.1 Heap Size Flags

Rule of thumb: For latency‑sensitive services, avoid frequent heap expansions (-Xms == -Xmx) to eliminate costly heap resizing events that trigger full GCs.

4.2 Young Generation Controls

A smaller young generation reduces minor GC pause time but can increase promotion frequency, leading to more work in the old generation. Conversely, a larger young generation reduces promotion pressure but can cause longer minor pauses. The sweet spot often lies around 25–30 % of total heap for services with high allocation rates.

4.3 Old Generation & Pause‑Time Targets

Example: A latency‑critical service on a 16‑core machine might use:

-XX:+UseG1GC \
-XX:MaxGCPauseMillis=30 \
-XX:InitiatingHeapOccupancyPercent=35 \
-XX:ParallelGCThreads=8 \
-XX:ConcGCThreads=8

4.4 Logging & Diagnostic Flags

Collecting these logs is the first step toward quantitative tuning—you cannot improve what you cannot measure.

5. Observability: Measuring and Diagnosing GC Pauses

5.1 GC Logs

A typical G1 GC log entry looks like this:

[2026-06-18T12:34:56.789+0000][0.123s][info][gc] GC(12) Pause Young (Concurrent Start) 512M->256M(1024M) 12.345ms

Key fields:

• Timestamp – When the pause began.
• Pause Young – Indicates a minor collection.
• 512M→256M – Heap before → after.
• 12.345ms – Duration of the pause.

Analyzing thousands of such entries with tools like GCViewer, GCEasy, or JDK Flight Recorder (JFR) reveals patterns: are pauses clustered during peak traffic? Is there a correlation between heap occupancy and pause length?

5.2 JFR (Java Flight Recorder)

JFR captures low‑overhead events, including:

• jdk.GCPhasePause – STW pause details.
• jdk.GCConcurrentPhase – Concurrent cycles.
• jdk.GCHeapSummary – Periodic heap size snapshots.

A sample JFR snippet:

{
  "eventType": "jdk.GCPhasePause",
  "startTime": "2026-06-18T12:34:56.789Z",
  "duration": 12345,
  "gcId": 12,
  "gcCause": "Allocation Failure",
  "gcName": "G1 Young Generation"
}

By correlating GC events with application-level metrics (e.g., request latency, thread pool queue depth), you can pinpoint whether a pause is the root cause of latency spikes.

5.3 VisualVM & Mission Control

Both tools ingest GC logs and JFR recordings, offering charts for:

• Young vs. Old GC time
• Heap occupancy over time
• Pause time distribution (percentiles)

For a service with a Service‑Level Objective (SLO) of 99th‑percentile latency ≤ 50 ms, a pause histogram should show 99th‑percentile pause ≤ 20 ms to leave headroom for application processing.

6. Latency‑Sensitive Workloads: Understanding Pause Impact

6.1 The Cost of a Stop‑the‑World

When the JVM pauses all application threads, any in‑flight request is stalled. In a microservice handling HTTP requests, a 30 ms GC pause adds directly to the response time. In a trading engine, a 30 ms pause can translate to $10 K of lost opportunity per million trades (based on average spread). The impact is therefore non‑linear: a single pause may affect many concurrent requests.

6.2 Real‑World Pause Distributions

Consider a production service running on a 32‑core machine with 16 GiB heap, using G1 GC. Over a 24‑hour window, the pause distribution might look like:

The 99.9th‑percentile pause is often the culprit for SLA violations. By tightening -XX:MaxGCPauseMillis to 20 ms, G1 will increase the number of regions per collection to meet the target, at the cost of higher CPU usage.

6.3 Strategies to Reduce Latency

7. Real‑World Tuning Walk‑Through

Let’s walk through a concrete scenario: a real‑time recommendation engine deployed in a Kubernetes pod, handling 10 k requests per second, with a latency SLO of ≤ 40 ms for the 99th percentile.

7.1 Baseline

• JDK: OpenJDK 17
• Collector: G1 (default)
• Heap: -Xms8g -Xmx8g (fixed)
• Pod Resources: 8 CPU, 16 GiB RAM

Initial GC logs (first hour) showed:

[0.342s][info][gc] GC(3) Pause Young (Allocation Failure) 6.2G->4.1G(8G) 56.7ms
[12.102s][info][gc] GC(27) Pause Full (Allocation Failure) 7.9G->6.3G(8G) 312.5ms

The max pause of 312 ms clearly violated the latency SLO.

7.2 Step 1 – Switch to ZGC

Because the service needed sub‑10 ms pauses, we switched to ZGC:

-XX:+UseZGC -Xms8g -Xmx8g -XX:ZCollectionInterval=500

After redeployment, the longest pause dropped to 9 ms. However, CPU usage rose to 85 % (from 55 %). The service still met the latency SLO but at the cost of higher CPU consumption, which impacted scaling.

7.3 Step 2 – Fine‑Tune G1 for Predictability

To reduce CPU load while keeping pauses ≤ 20 ms, we reverted to G1 with aggressive tuning:

-XX:+UseG1GC \
-XX:MaxGCPauseMillis=20 \
-XX:InitiatingHeapOccupancyPercent=30 \
-XX:NewRatio=3 \
-XX:MaxTenuringThreshold=4 \
-XX:ParallelGCThreads=6 \
-XX:ConcGCThreads=6

Result:

The 99.9th‑percentile pause now comfortably fits under the latency budget, and CPU usage stays within the pod’s limit.

7.4 Step 3 – Application‑Level Optimizations

We added an object pool for the frequently created UserScore objects (average size 256 bytes). By reusing these objects, allocation rate dropped by 30 %, leading to fewer minor GCs. The final pause distribution:

The service now consistently meets its SLO, with a modest CPU increase (≈ 65 %). This case study illustrates how collector choice, JVM flags, and application design work together to achieve latency guarantees.

8. Bridging to Bees, AI Agents, and Conservation

At first glance, Java GC and bee colonies seem worlds apart. Yet the generational principle that underpins both systems is strikingly similar:

• Bee colonies allocate resources to brood (young bees) and foragers (older, experienced workers). The colony constantly evaluates the ratio of larvae to foragers, adjusting the queen’s egg‑laying rate and the workers’ feeding behavior. When food is abundant, more larvae survive; when scarce, the colony throttles brood production, preserving older foragers that can bring in nectar.

• The JVM allocates memory to young objects (Eden) and old objects (tenured). The GC monitors survival rates; if many objects survive several minor collections, they are promoted, reducing churn in the young generation. During memory pressure, the collector may shrink the young generation, analogous to a colony limiting brood during drought.

These parallels inspire a self‑governing AI agent design pattern: an agent could maintain a generational memory pool where short‑lived knowledge (e.g., temporary sensor readings) resides in a fast, volatile store, while long‑term policies are promoted to a stable repository. By borrowing the adaptive sizing mechanisms from the JVM (e.g., -XX:+UseAdaptiveSizePolicy), an AI could automatically rebalance its memory structures based on workload, avoiding “memory leaks” that would otherwise degrade performance.

From a conservation perspective, the same feedback loops that keep a bee hive healthy can be modeled in software to maintain ecosystem simulations. When simulating pollinator dynamics, the age distribution of agents influences resource consumption; a well‑tuned GC mirrors that natural regulation, ensuring the simulation runs efficiently without artificial bottlenecks.

Thus, understanding GC is not merely a Java‑centric concern—it offers a biologically inspired framework for building resilient, self‑optimizing AI systems that respect both computational limits and ecological realities.

9. The Road Ahead: AI‑Driven GC and Emerging Collectors

The next frontier in garbage collection is autonomous, AI‑augmented tuning. Already, the JVM’s Adaptive Size Policy uses heuristics to adjust generation sizes based on allocation rates. Future work aims to replace those heuristics with reinforcement‑learning agents that observe metrics (heap occupancy, pause latency, CPU usage) and dynamically select collector parameters to optimize a multi‑objective reward (e.g., minimize pause while maximizing throughput).

9.1 Emerging Collectors

9.2 AI‑Assisted Tuning Pipelines

A practical implementation could look like:

1. Data Ingestion – Collect GC logs, JFR events, and application metrics in a time‑series database (e.g., Prometheus).
2. Feature Extraction – Derive features such as “allocation rate per second,” “average survivor ratio,” and “pause‑time percentile.”
3. Policy Learning – Train a reinforcement‑learning agent (e.g., Proximal Policy Optimization) to suggest flag adjustments.
4. Action Execution – Apply the new flags via a rolling restart or hot‑swap (e.g., jcmd VM.set_flag).
5. Feedback Loop – Monitor the impact and refine the model.

Such a pipeline would allow a self‑governing AI agent to manage its own memory footprint, similar to how a bee colony self‑regulates brood size. In the context of Apiary’s mission, this approach can be used to simulate large‑scale pollinator networks without overwhelming the host JVM, ensuring that research simulations remain both accurate and efficient.

Why It Matters

Garbage collection is the invisible hand that keeps Java applications alive, performant, and responsive. For latency‑critical services, the difference between a 10 ms pause and a 200 ms pause can be the line between meeting an SLA and triggering a cascade of failures. By mastering generational algorithms, fine‑tuning the right JVM flags, and leveraging modern observability tools, engineers can shape GC behavior to match the strictest latency budgets.

Beyond the code, the generational philosophy resonates with natural systems—bee colonies, ecosystems, and even autonomous AI agents—all of which thrive by dynamically balancing short‑term growth and long‑term stability. By internalizing those lessons, we build software that not only runs faster but also mirrors the resilience of the very world we aim to protect.

In short: understanding and controlling GC is a cornerstone of robust, eco‑aware software engineering. It empowers us to deliver high‑performance Java services, to simulate complex biological processes without choking on memory, and to craft AI agents that responsibly manage their own resources—just as a bee colony does every day.