Master G1 GC Logs: Enable, Read, and Analyze Java Garbage Collection Details

This guide explains how to enable detailed G1 GC logging in Java, interprets both Minor (YGC) and Full GC log entries, breaks down heap size changes, worker threads, pause times, and points to the GCEasy analysis tool for deeper insight.

JavaEdge
JavaEdge
JavaEdge
Master G1 GC Logs: Enable, Read, and Analyze Java Garbage Collection Details

0 Introduction

G1 (Garbage-First) is the default garbage collector in Java 9 and optional in Java 8. It aims to limit pause times while maintaining overall throughput.

Understanding the G1 GC log format is essential for JVM tuning and troubleshooting. Tools such as GCEasy (http://gceasy.io/) can help parse the logs.

1 Enable Detailed GC Logging

Use the following JVM options to produce a detailed GC log with timestamps:

-Xloggc:/home/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps

The log file will be written to /home/gc.log.

2 Minor GC (YGC) Log Example

Typical Minor GC (young generation) entry:

Minor GC log example
Minor GC log example

2.1 Timestamp

2024‑07‑10T15:04:37.929+0800: 20197.284 – the GC occurred 20 197.284 ms after JVM start.

2.2 Pause Type

G1 Evacuation Pause – live objects are copied from the young (or young+old) region to other regions.

2.3 Generation

"young" indicates a YGC event.

2.4 Worker Threads

GC Workers: 4 – four parallel GC worker threads were used.

2.5 Heap Size Changes

[Eden: 2016.0M(2016.0M)->0.0B(2016.0M) Survivors: 32.0M->32.0M Heap: 2076.8M(4096.0M)->60.0M(4096.0M)]

Interpretation:

Eden : 2016 MB used, fully occupied before GC; after GC it becomes 0 B while the capacity remains 2016 MB.

Survivors : 32 MB before and after GC, showing objects promoted to survivor space.

Heap : Total heap size stays at 4096 MB; used space drops from 2076.8 MB to 60 MB, meaning ~2016 MB reclaimed.

Times : user=0.12 s, sys=0.04 s, real=0.08 s – the pause lasted 0.08 seconds.

3 Full GC Log Example

Typical Full GC entry:

Full GC log example
Full GC log example

3.1 Timestamp

2015‑09‑14T12:35:27.263-0700 – time of GC.

183.216 – GC occurred 183.216 seconds after JVM start.

3.2 Cause

Full GC (Allocation Failure) – triggered when the heap cannot satisfy a memory allocation, often due to fragmentation in the old generation.

3.3 Heap Size Changes

[Eden: 3072.0K(194.0M)->0.0B(201.0M) Survivors: 0.0B->0.0B Heap: 3727.1M(4022.0M)->3612.0M(4022.0M)], [Metaspace: 2776K->2776K(1056768K)]

Interpretation:

Eden : 194 MB capacity, 3072 KB used before GC; after GC it becomes 0 B and capacity expands to 201 MB.

Survivors : Remain 0 KB before and after GC.

Heap : Total heap 4022 MB; used space drops from 3727.1 MB to 3612.0 MB, reclaiming ~115 MB.

Metaspace : Usage unchanged at 2776 KB; total capacity 1 056 768 KB.

Times : user=19.08 s, sys=0.01 s, real=9.74 s – the pause lasted 9.74 seconds.

4 References

https://tech.meituan.com/2016/09/23/g1.html

https://www.oracle.com/technetwork/tutorials/tutorials-1876574.html

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

JavaGarbage Collectionperformance tuningg1gcGC Logs
JavaEdge
Written by

JavaEdge

First‑line development experience at multiple leading tech firms; now a software architect at a Shanghai state‑owned enterprise and founder of Programming Yanxuan. Nearly 300k followers online; expertise in distributed system design, AIGC application development, and quantitative finance investing.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.