Java 10 reduces Full GC pause times by iteratively improving on its existing algorithm.
-XX:ParallelGCThreads
As I understood it G1 does not run its collection cycles concurrently with our application. It will still pause the application periodically and Full GC pauses increase with larger heap sizes.
Then how does it improve performance? Can anyone explain this?
Because it wasn't until Java 10 that G1GC became fully parallel in stop-the-world full GC cycle. As per JEP 307: Parallel Full GC for G1 this improves the latency of the worst case scenario:
The G1 garbage collector is designed to avoid full collections, but when the concurrent collections can't reclaim memory fast enough a fall back full GC will occur. The current implementation of the full GC for G1 uses a single threaded mark-sweep-compact algorithm. We intend to parallelize the mark-sweep-compact algorithm and use the same number of threads as the Young and Mixed collections do. The number of threads can be controlled by the -XX:ParallelGCThreads option, but this will also affect the number of threads used for Young and Mixed collections.
In fact, Java 11 is recommended if you use G1GC because a lot of works was done on it to reduce its footprint and lower its pauses compared to 10.
A summary was done on the hotspot-gc-use mailing list around the various improvements made on 11, 10 and 9 for G1GC, you can find it at this link: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/2018-June/002759.html
A quick summary from this post on the list :
[...] I would like to point out that overall, with G1, compared to JDK8 it is possible to get 60% lower pause times "for free" on x64 processors (probably more on ARM/PPC due to mentioned specific changes), at a highly reduced memory footprint.
