JEP draft: Improve G1 worst-case latencies by making the full GC parallel
|Component||hotspot / gc|
|Discussion||hotspot dash gc dash dev at openjdk dot java dot net|
|Reviewed by||Mikael Vidstedt|
Improve G1 worst-case latencies by making the full GC parallel.
- For all use-cases match the performance of the full GC in the Parallel collector.
The G1 garbage collector was made the default in JDK 9. The previous default, the Parallel collector, has a parallel full GC and to minimize the impact for users experiencing full GCs the G1 full GC should be made parallel as well.
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 is using a single threaded version mark-sweep-compact algorithm. The idea is to parallelize the mark-sweep-compact algorithm and scale the number of threads used with regards to heap layout and size.
- Full GC time analysis to ensure that the full GC times have improved. Looking at benchmark score will probably not be good enough since G1 is designed to avoid full GC.
- Runtime analysis using VTune or Solaris Studio Performance Analyzer to find unnecessary bottlenecks.
Risks and Assumptions
- The work is based on the assumption that nothing in the fundamental design of G1 prevents a parallel full GC.
- The fact that G1 uses regions will most likely lead to more wasted space after a parallel full GC than for a single threaded one.