GC Logging Analysis: Decoding JVM Garbage Collection Logs

Garbage collection logs are one of the most valuable sources of information when troubleshooting JVM memory issues. When your application starts exhibiting slowdowns, frequent GC pauses, or memory-related errors, GC logs tell the story that profilers and monitoring tools often cannot. This guide teaches you how to enable comprehensive GC logging, interpret the output, and leverage powerful visualization tools to diagnose performance problems.

Modern JVMs provide extremely detailed GC logging through the -Xlog:gc flag, which replaced the legacy -XX:+PrintGCTimestamps and -XX:+PrintGCDetails flags in Java 9+. The new logging framework is more flexible, allows fine-grained control over what gets logged, and outputs data in a format that tools can parse reliably.

Introduction

When your Java application starts exhibiting slowdowns, frequent GC pauses, or memory-related errors, garbage collection logs tell the story that profilers and monitoring tools often cannot. GC logs record every garbage collection event with timing, memory before and after, pause duration, and the cause of each collection. This information is essential for diagnosing memory issues, tuning GC configuration, and understanding how your application behaves under different allocation patterns.

Modern JVMs provide detailed GC logging through the -Xlog:gc unified logging framework introduced in Java 9, which replaced the legacy -XX:+PrintGCTimestamps and -XX:+PrintGCDetails flags. The new system is more flexible and outputs data in a machine-parseable format that tools like GCEasy and GCViewer can analyze to spot patterns like memory leaks, allocation rate spikes, and metaspace exhaustion.

This guide teaches you how to enable comprehensive GC logging, interpret the output from different GC algorithms, and leverage visualization tools to diagnose performance problems. You will learn what each log entry means, how to identify normal versus problematic GC patterns, and how to correlate GC events with application metrics and deployments to establish baseline behavior and detect anomalies.

When to Use GC Logging / When Not to Use GC Logging

GC logging shines in several scenarios. During performance testing before production release, GC logs reveal whether your heap sizing and collector selection handle your application’s allocation patterns effectively. When investigating production incidents involving memory pressure or latency spikes, GC logs from that timeframe provide crucial forensic data. Capacity planning also benefits enormously from GC log analysis, as historical data shows how memory usage scales with load.

However, GC logging is not always the right tool. In development environments where you are making rapid code changes, the overhead of detailed GC logging can mask actual code-level performance issues. For short-lived applications that complete quickly, the overhead may not justify the insights gained. If latency-critical trading systems require every microsecond, even the minimal overhead of GC logging might be unacceptable during live trading hours—capture logs during off-hours instead.

GC logging also produces substantial data volume. A moderately busy application can generate hundreds of megabytes of log data per day. Plan your log rotation and storage accordingly. For 24/7 production systems, always enable GC logging at a reasonable level; the operational intelligence gained far outweighs the storage cost.

Architecture of JVM Garbage Collection

Understanding how the JVM organizes memory helps you interpret GC logs effectively.

graph TD
    subgraph "JVM Heap Memory"
        subgraph "Young Generation"
            ED[Eden<br/>New objects allocated here]
            S0[Survivor Space 0<br/>Survivors from Eden]
            S1[Survivor Space 1<br/>Survivors from S0]
        end
        subgraph "Old Generation"
            OG[Old Generation<br/>Long-lived objects promoted]
        end
        subgraph "Metaspace"
            MS[Metaspace<br/>Class metadata, no GC]
        end
    end

    ED -->|"Minor GC<br/>Copying survivors"| S0
    S0 -->|"Aging"| OG
    S0 <-->|"Copying during GC"| S1
    ED -->|"Major/Full GC<br/>Mark-Compact"| OG

The diagram shows the generational memory architecture. Objects allocate in Eden, survive minor GCs in survivor spaces, and eventually promote to the old generation. Understanding this flow helps you interpret why certain GC events occur and what they mean for your application.

## Enabling GC Logging

Modern Java versions use the unified logging system introduced in Java 9. Enable GC logging with the `-Xlog` flag:

```bash
# Basic GC logging to file
java -Xlog:gc*:file=gc.log:time,uptime -jar your-application.jar

# Detailed logging with tags for different GC phases
java -Xlog:gc*=info:file=gc-detail.log:time,uptime,tags -jar your-application.jar

# Minimal overhead production logging
java -Xlog:gc=info:file=gc-production.log:time,uptime -jar your-application.jar

# Log rotation configuration
java -Xlog:gc*:file=gc-%t.log:time,filecount=10,filesize=100M -jar your-application.jar

The format breaks down as follows. gc* selects all GC-related log messages. file=gc.log specifies the output file. time,uptime,tags control what information appears in each line. The filecount and filesize options enable automatic rotation, critical for production systems.

For Kubernetes deployments, direct logging to stdout so the container orchestrator can handle rotation:

java -Xlog:gc*=info:stdout -jar your-application.jar

Understanding GC Log Output

A typical minor GC event looks like this:

[2026-05-26T10:15:32.145+0000][29845.432][gc      ] GC(12) Pause Young (Normal)
 GC(12) Heap before: used=245M, committed=512M, allocated=512M
 GC(12)   young: 245M -> 0B; [Metaspace: 48M -> 48M]
 GC(12) Heap after: used=89M, committed=512M, allocated=512M
 GC(12)   old: 67M -> 89M; [Metaspace: 48M -> 48M]

This shows a minor GC that reclaimed 156 MB from the young generation. The old generation grew slightly from 67 MB to 89 MB because some long-lived objects survived. The pause lasted long enough to be logged but was not severe enough to cause concern.

A Full GC event requires more attention:

[2026-05-26T10:15:45.678+0000][29858.965][gc      ] GC(13) Pause Full (Allocation Failure)
 GC(13) Heap before: used=471M, committed=512M, allocated=512M
 GC(13)   metaspace: 52M -> 52M
 GC(13) Heap after: used=156M, committed=512M, allocated=512M
 GC(13)   old: 423M -> 108M; [Metaspace: 52M -> 52M]

Full GCs occur when the old generation cannot accommodate an allocation request or when the permanent generation fills. The pause time on Full GCs is typically an order of magnitude greater than minor GCs, making them the primary culprit in latency-sensitive applications.

GC Log Analysis Tools

GCEasy

GCEasy is a web-based tool that accepts uploaded GC logs and produces detailed analysis. It identifies the GC algorithm in use, calculates pause times and throughput, detects memory leak trends, and provides actionable recommendations.

For logs stored in a file:

# Upload to GCEasy (requires API key for automation)
curl -F "file=@gc.log" https://api.gceasy.io/analyzeGC

# Or use the web interface
# https://gceasy.io

GCEasy excels at identifying problems that require experience to spot. It recognizes patterns like “metaspace exhaustion,” “allocation rate spikes,” and “degenerate GCs” that indicate collector misconfiguration.

GCViewer

GCViewer is an open-source desktop tool for visualizing GC logs. It renders charts showing heap usage over time, pause time distribution, and throughput calculations.

# Download from GitHub releases
wget https://github.com/chewiebug/GCViewer/releases/download/v1.34.1/standalone-javafx-1.34.1.jar

# Run with Java 11+
java -jar gcviewer-1.34.1.jar gc.log

Key metrics GCViewer provides include total pause time, average pause time, maximum pause time, and throughput percentage. The visual representation makes it easy to spot problem periods that correlate with application behavior or deployment events.

Other Tools

GCPlot is a self-hosted or cloud-based option for teams that want to analyze logs programmatically. IBM GC Extension for Health Center provides deep analysis for WebSphere environments. Amazon Corretto users have access to the Amazon инструменты for GC analysis in AWS environments.

Production Failure Scenarios

Scenario 1: Continuous Full GC Due to Memory Leak

A production service suddenly starts experiencing Full GC every few minutes. The old generation fills up immediately after each Full GC, causing another. This classic pattern indicates objects leaking into the old generation—typically caches without eviction, static collections, or object pools that grow unboundedly.

Diagnosis involves comparing heap dumps before and after a Full GC cycle. Look for objects that should not survive minor GC but appear in the old generation. The jmap -histo command helps identify large object arrays or unexpected class instances.

Scenario 2: GC Thrashing Under High Allocation Rate

An application with bursty traffic experiences severe performance degradation during traffic spikes. GC logs show extremely frequent minor GCs with high allocation rates, sometimes followed by Full GCs when the young generation cannot keep up.

This indicates the heap is too small for the application’s allocation pattern. The young generation especially suffers because objects promoting to old generation include ones that should have died in survivor spaces.

Scenario 3: Metaspace Exhaustion

Modern applications using reflection, dynamic proxies, or heavy classloading can exhaust Metaspace. Before Java 8, this would have been PermGen space. Metaspace grows dynamically but garbage collects classloaders when they become unreachable.

Logs show Metaspace increasing steadily, then hitting the configured limit. If MaxMetaspaceSize is set too low, you will see “OutOfMemoryError: Metaspace” errors.

Trade-off Table

Aspect	Minor GC	Full GC	G1 GC	ZGC
Pause Time	1-50ms typically	100ms-2s	<200ms target	<1ms target
Throughput Impact	Low	High	Medium	Minimal
Memory Efficiency	Good for short-lived objects	Poor for large heaps	Adaptive	Excellent
Configuration Complexity	Medium	Low	High	Medium
Best For	Batch workloads	Small heaps	Responsive apps	Ultra-low latency

Implementation Snippets

Analyzing GC Logs Programmatically

import java.io.BufferedReader;
import java.io.FileReader;
import java.util.regex.*;

public class GcLogAnalyzer {
    // Pattern for pause time extraction
    private static final Pattern PAUSE_PATTERN =
        Pattern.compile("Pause (Young|Old|Full).*?(\\d+\\.\\d+)ms");

    public static void main(String[] args) throws Exception {
        double totalPauseTime = 0;
        int gcCount = 0;

        try (BufferedReader reader = new BufferedReader(
                new FileReader("gc.log"))) {
            String line;
            while ((line = reader.readLine()) != null) {
                Matcher matcher = PAUSE_PATTERN.matcher(line);
                if (matcher.find()) {
                    double pauseTime = Double.parseDouble(matcher.group(2));
                    totalPauseTime += pauseTime;
                    gcCount++;
                    System.out.printf("GC #%d: %.2fms%n", gcCount, pauseTime);
                }
            }
        }

        System.out.printf("%nTotal GC pauses: %d%n", gcCount);
        System.out.printf("Average pause: %.2fms%n", totalPauseTime / gcCount);
        System.out.printf("Total pause time: %.2fms%n", totalPauseTime);
    }
}

Automated Log Upload

#!/bin/bash
# Upload recent GC logs to GCEasy for analysis
LOG_FILE="gc-production.log"

if [ -f "$LOG_FILE" ]; then
    RESPONSE=$(curl -s -F "file=@$LOG_FILE" \
        -F "apiKey=YOUR_API_KEY" \
        https://api.gceasy.io/analyzeGC)

    echo "$RESPONSE" | jq -r '.gceasyUrl // .error'
else
    echo "GC log file not found: $LOG_FILE"
fi

Observability Checklist

Before declaring a GC issue resolved, verify these points. Throughput should meet your SLAs—typically 95% or higher for production services. Pause times should remain below your latency budget; for most applications, sub-200ms pauses are acceptable. No continuous Full GC cycles should occur. Memory usage should stabilize after warmup, not grow unboundedly. Object promotion rates should be reasonable relative to your application lifetime.

Monitor these metrics over at least one full load cycle to ensure the patterns observed are consistent and not anomalies.

Security and Compliance Notes

GC logs contain sensitive information about your application’s memory usage patterns. Object class names can reveal implementation details, and string content in objects may expose user data or internal system information. Protect GC logs accordingly—encrypt them at rest and restrict access to operations and performance teams.

In regulated industries, GC logs may fall under operational audit requirements. Document why you enabled specific logging levels and retain logs according to your data retention policy.

Never expose GC log analysis tools to untrusted networks. Tools like GCEasy process sensitive memory data; ensure you understand their data handling policies before uploading production logs.

Common Pitfalls / Anti-Patterns

The most frequent mistake is enabling too much logging in production. Verbose GC logging with all tags enabled creates significant overhead and generates enormous log volumes. Start with minimal logging and add tags only when investigating specific issues.

Another common error is analyzing logs from the wrong time window. GC behavior during application startup differs dramatically from steady-state operation. Always compare logs from similar application lifecycle phases.

Misinterpreting Full GC causes leads to ineffective solutions. Not every Full GC indicates a problem. Some Full GCs are normal—metaspace garbage collection, or Java heap dumps triggered programmatically, or System.gc() calls from application code.

Finally, tuning GC without load testing produces misleading results. What works under test load may fail under production traffic patterns. Always validate GC tuning changes with realistic workloads.

Quick Recap Checklist

• Enable GC logging in production with -Xlog:gc=info:file=gc.log
• Use log rotation to manage volume: filecount=10,filesize=100M
• Analyze logs with GCEasy for automated insights and GCViewer for visualization
• Distinguish normal GC patterns from problematic ones
• Correlate GC events with application metrics and deployment events
• Test any tuning changes under realistic load before production deployment
• Protect GC logs—they contain sensitive memory information

Interview Questions

Further Reading

• GCEasy - Free Online GC Log Analyzer — Upload GC logs for automated analysis and recommendations
• GCViewer - GitHub — Open-source GC log visualization tool for desktop
• Java SE 11 GC Tuning Guide — Official Oracle documentation for GC tuning
• Understanding Garbage Collection Logs — Oracle’s comprehensive GC logging documentation
• -Xlog Unified Logging Reference — Complete reference for Java 9+ unified logging syntax

Conclusion

GC logging remains one of the most valuable diagnostic tools for understanding JVM memory behavior. Enable -Xlog:gc=info in production with appropriate log rotation to capture the data you need for incident investigation. Use GCEasy or GCViewer to analyze logs and identify patterns like memory leaks, allocation rate issues, and metaspace exhaustion.

Correlate GC events with application metrics and deployments to establish baseline behavior and detect anomalies. For memory issues, GC logs tell the story that profilers cannot. The investment in proper log configuration pays off during production incidents when you need to understand exactly what the JVM was doing at the moment of failure.