Explanation needed about Parallel Full GC for G1

Question

As part of the java JDK10 JEP307 was Parallel Full GC for G1 realsed.

I've tried to grasp its description, but I am still not confident that I got the idea properly.

my doubt was is it related to Concurrent Garbage

Answer 1

As a simplified explanation - garbage collectors have two possible collection types, "incremental" and "full". Incremental collection is the better of the two for staying out the way, as it'll do a little bit of work every so often. Full collection is often more disruptive, as it takes longer and often has to halt the entire program execution while it's running.

Because of this, most modern GCs (including G1) will generally try to ensure that in normal circumstances, the incremental collection will be enough and a full collection will never be required. However, if lots of objects across different generations are being made eligible for garbage collection in unpredictable ways, then occasionally a full GC may be inevitable.

At present, the G1 full collection implementation is only single threaded. And that's where that JEP comes in - it aims to parallelize it, so that when a full GC does occur it's faster on systems that can support parallel execution.

Answer 2

Finally I understood about Parallel Full GC for G1

Made the default in JDK 9 and Introduced in JDK 7

Efficiently and concurrently deal with heaps fails on Full Garbage Collection some times full Garbage Collection is inevitable.It efficiently and concurrently deal with very large heaps Normal GC would divide the heap into young (eden and survivor) and old generation (logical separation) G1 splits heap into many small regions. This splitting enables G1 to select a small region to collect and finish quickly.

In JDK9 uses single thread for full GC

In JDK 10 uses multi thread(parallel) for Garbage Collection'

Answer 3

The G1 garbage collector was infamous for doing a single-threaded full GC cycle. At the time when you need all the hardware that you can muster to scrounge for unused objects, we bottlenecked on a single thread. In Java 10 they fixed this. The full GC now runs with all the resources that we throw at it. To demonstrate this, I wrote ObjectChurner, which creates a bunch of different sized byte arrays. It holds onto the objects for some time. The sizes are randomized, but in a controlled, repeatable way.

Answer 4

Java 10 reduces Full GC pause times by iteratively improving on its existing algorithm. Until Java 10 G1 Full GCs ran in a single thread. That’s right - your 32 core server and it’s 128GB will stop and pause until a single thread takes out the garbage. In Java 10 this has been improved to run in Parallel. This means that the Full GCs will be on multiple threads in parallel, albeit still pausing the JVM’s progress whilst it completes. The number of threads can be optionally configured using -XX:ParallelGCThreads.

This is a nice improvement to the G1 algorithm in Java 10 that should reduce worst case pause times for most users. Does that mean that Java GC pauses are a thing of the past? No - it reduces the problem but since G1 doesn’t run its collection cycles concurrently with your application it will still pause the application periodically and Full GC pauses still increase with larger heap sizes. We’ve talked about some other Garbage Collectors in our last blog post that may solve this problem in future.

Answer 5

G1 Collector
Another beautiful optimization which was just out with Java 8 update 20 for is the G1 Collector String deduplication. Since strings (and their internal char[] arrays) takes much of our heap, a new optimization has been made that enables the G1 collector to identify strings which are duplicated more than once across your heap and correct them to point into the same internal char[] array, to avoid multiple copies of the same string from residing inefficiently within the heap. You can use the -XX:+UseStringDeduplicationJVM argument to try this out.

Parallel Full GC in G1GC
The G1 garbage collector was infamous for doing a single-threaded full GC cycle. At the time when you need all the hardware that you can muster to scrounge for unused objects, we bottlenecked on a single thread. In Java 10 they fixed this. The full GC now runs with all the resources that we throw at it.

JVM parameters: -Xlog:gc,gc+cpu::uptime -Xmx4g -Xms4g -Xlog:gc*:details.vgc This will output each GC event and its CPU usage to stdout, showing only the uptime as a tag. The setting -Xlog:gc* is like the -XX:+PrintGCDetails of previous Java versions.