G1 Garbage Collector Diagnosis and Tuning

Quick answer

G1 is the default collector on most Java 25 server configurations and aims for relatively uniform pauses with good throughput. Diagnose it by following the young-only phase, concurrent marking, mixed collections, region occupancy, remembered-set work, object copying, evacuation headroom, humongous allocations, and adaptive IHOP. Tune only after the log identifies which goal is missed and the application or capacity cause is understood.

Start with G1 defaults, a deliberate maximum heap, and an explicit service objective. Avoid copying historical flag bundles. Fix excessive allocation, retention, undersized container memory, or CPU throttling before trying to force G1 heuristics around the underlying problem.

Learning objectives

• Read a Java 25 G1 cycle from young-only collections through marking and mixed collection reclamation, including evacuation and humongous-object risks.
• Choose a minimal, reversible G1 experiment tied to latency, throughput, memory, and user outcomes rather than tuning from folklore.

Prerequisites

Read JVM GC Logs and Pause Diagnosis and understand allocation rate, live set, pause time, and concurrent collector CPU. Use Java Heap Dumps and Memory Leak Analysis when object retention, rather than collection mechanics, is the active question.

Evidence and system boundary

G1 divides the heap into regions and selects regions for evacuation. A normal cycle moves from young-only work into concurrent marking and then a space-reclamation phase with mixed collections. Remembered sets track cross-region references. During a pause, G1 scans roots and remembered information, copies live objects, and updates references. Concurrent work still consumes CPU alongside the Spring order service.

The following is an explanatory diagnostic example, not an executed recommendation:

java -Xlog:gc*,gc+phases=debug,gc+heap=info:file=g1.log:time,uptime,level,tags -jar order-service.jar

Deep phase logging increases volume. Bound the interval, rotate files, and preserve the exact JDK update and flags with the capture.

Follow the G1 cycle

Young collections evacuate surviving objects and adapt the young generation to a pause-time goal. Concurrent marking estimates region liveness while the application runs. Mixed collections add selected old regions to collection sets so G1 can reclaim old space incrementally. If marking begins too late, live data grows too quickly, or CPU prevents concurrent progress, G1 can lose reclamation headroom.

Adaptive IHOP predicts when marking should begin from observed marking duration and old-generation allocation. Disabling it or forcing one occupancy threshold transfers responsibility to the operator and can make changing workloads less safe. Treat a manual threshold as a measured experiment, not a default template.

Evacuation needs free regions for copied objects. Evacuation failure means that headroom was insufficient; inspect live-set growth, allocation bursts, heap sizing, CPU, and repeated collections. A Full GC may follow extreme pressure. Increasing heap can add headroom, but it also changes memory footprint and potentially recovery time, so verify container and node capacity.

Humongous objects occupy one or more regions and can trigger early collection or fragmentation pressure. Use gc+heap=info and allocation evidence to find the responsible shapes. Do not change region size first; reduce avoidable large allocations or stream data when the application contract permits.

Tuning in evidence order

For excessive pause duration, identify the dominant phase before adjusting the pause goal. Root and remembered-set scanning, object copying, reference processing, and OS scheduling require different remedies. For throughput loss, measure concurrent and pause CPU, allocation, JIT, and container throttling. Relaxing an unrealistic pause goal may improve throughput; forcing a smaller young generation can increase collection frequency and undermine G1’s adaptive control.

Change one owned setting at a time. Keep the workload, version, heap, container limits, and traffic shape comparable. Validate p50/p95/p99 latency, throughput, errors, GC CPU, pause distribution, allocation, after-collection occupancy, RSS, dependency load, and durable order results.

Production failure scenario

A Spring order service starts allocating large temporary response buffers. G1 logs show humongous allocations, early concurrent starts, longer object-copy work, and occasional evacuation failure. The post-collection live set is otherwise stable.

The team removes the duplicate buffering in a canary and keeps G1 defaults. Humongous allocation and evacuation failures disappear, pauses and CPU improve, and checkout results remain correct. Only after that comparison would a heap or pause-goal experiment be justified. The log evidence supports the allocation mechanism; fresh user and order evidence support recovery.

Common misconceptions

• MaxGCPauseMillis is a goal, not a per-pause guarantee.
• A larger heap is not a free fix; it consumes container and node memory and can hide retention.
• Fixed young-generation sizing can disable an important part of G1 pause adaptation.
• Humongous does not mean an object is invalid; it means its size interacts differently with regions.
• A G1 Full GC does not identify the retained objects or prove an application leak.

Decision checklist

• Start from G1 defaults and record the exact Java 25 update and effective flags.
• Classify young, marking, mixed, Full GC, and evacuation events in one timeline.
• Compare after-collection occupancy, allocation, concurrent CPU, and container limits.
• Identify the dominant pause phase before changing a pause goal.
• Investigate humongous allocation at the application boundary before changing region size.
• Preserve adaptive IHOP unless a repeatable workload proves a specific alternative.
• Change one variable with a canary and rollback path.
• Verify user latency, throughput, RSS, dependencies, and durable order outcomes.

Related reading

Compare the low-latency alternative in ZGC Diagnosis and Tuning, then continue to Java Heap Dumps and Memory Leak Analysis. Follow the full Java Concurrency course and topic cluster.

Official sources

• Java 25 G1 Garbage Collector
• Java 25 G1 tuning guidance
• Java 25 HotSpot GC Tuning Guide
• Java 25 java command

Official sources accessed August 19, 2026. G1 ergonomics and diagnostic options are HotSpot and release specific; verify the exact vendor runtime before applying a flag.