In this section, we will have a look at the G1 GC logs in detail.

The following features are marked in the following screenshot:

1. Each heap region is of the size, 1M.
2. The JVM is using G1 as its GC.
3. The G1 collector starts a young collection 0.309 seconds after starting the application execution.
4. The G1 collector uses multiple threads for the young collection.

5. The G1 collector moves live objects from 14 Eden regions to 2 Survivor regions:

Let's examine another section of the same GC log, as follows:

The logs in the preceding screenshot are part of the same GC collection (note GC (5) in the logs). It shows logs from another young collection by the G1 GC. I've highlighted the Eden, Survivor, Old, and Humongous regions that the collector worked on. The values on the left side of the arrows show the counts of regions before the collection, and the values on the right are the counts of regions after the GC.

Let's examine the last section of the G1 log before the JVM quits with OutOfMemoryError, as follows:

1. The collection uses multiple threads for the full collection.
2. Full GC starts.
3. Full GC includes a multiple number of steps, including marking live objects, preparing for compaction, adjusting pointers, and compacting the heap.
4. As you will notice, there are no more Eden regions and Survivor regions available for allocation and compaction (0 -> 0). The Old and Humongous regions contain live objects that can't be collected. As a result, the JVM shuts down with OutOfMemoryError.
5. This information logs the actual time taken by the full GC:

The bottom of the preceding screenshot includes a few final statistics, including total heap size, used heap size, region size, and more.