G1 GC divides the Java heap into regions and organizes objects by lifecycle. It collects regions through young-generation evacuation, tracks survivor and old regions, and reports humongous objects separately. section 11.1
Use GC logs to investigate whether collection causes application delays, whether memory is reclaimed efficiently, and whether available CPU is being used effectively. A short pause is reassuring; frequent pauses above 50 milliseconds warrant investigation. section 11.1 section 11.4.4
Inspect these signals when diagnosing G1 GC behavior:
- Identify the collector, heap region size, initial capacity, maximum capacity, and worker counts during JVM initialization. section 11.1
- Check whether a collection is a young-generation G1 evacuation pause and measure its individual phases. section 11.1
- Compare Eden, survivor, old, and humongous regions before and after collection to understand what was reclaimed or promoted. section 11.1
- Compare GC worker usage with available CPUs; underuse can lengthen pauses, while excessive parallelism can consume application CPU. section 11.4.4
Reading one collection
A log showing an 8 MB region size, a roughly 12 GB maximum heap, and a young G1 evacuation pause at 1.336 seconds describes a small collection event. Eden changes from four regions to zero, one survivor region appears, and old and humongous regions remain empty. Phase timings totaling only a few milliseconds indicate efficient collection with little observable disruption. section 11.1
-Xlog:gc*
Enable unified GC logging with -Xlog:gc* while running the application, then inspect initialization, pause, phase, and heap-change entries. section 11.1
