JEP 144: Reduce GC Latency for Large Heaps
|Discussion||hotspot dash gc dash dev at openjdk dot java dot net|
Improve the performance of applications that require large heaps, of up to 32GB, by reducing garbage-collector latency.
Enable the use of 32GB heaps with 60% live data and fairly consistent 250–500ms pause times, as specified by pause target, for a set of relevant benchmarks. Average pause times can fluctuate ±10%.
Pause-time guarantees are not required. It is not a goal or a requirement to improve GC characteristics for smaller heap sizes that are currently served well by existing GC technology.
We see continued increases in random-access memory (RAM) sizes. For workloads that require low and consistent GC pause times, the JVM using the CMS collector can manage heap sizes of up to 4–8GB. A normal low-cost server now has much more memory than can be effectively used with a single JVM instance for these workloads, so Java applications are often scaled out across several JVM instances. While this may be a viable solution for many applications, vertical scaling solutions are effectively blocked by JVM GC limitations. Non-garbage-collected environments do not suffer from these limitations. The intent of this proposal is to enable low and consistent pause times with large RAM sizes so that Java is viable for existing use cases where GC limitations have forced complicated re-architecting or migration to other platforms.
This will done by improving the G1 collector. There are a number of CRs that we aim to work on to improve performance. The list below is our starting point; it is not the final list of CRs. Extensive performance measurements are required to find the actual bottlenecks and choose the CRs (and write new ones) for those areas where more work is needed.
6484965: G1: piggy-back liveness accounting phase on marking
6868854: G1: eliminate serial Other times at the end of a GC pause
6949254: G1: introduce framework for concurrent operations in G1
6976060: G1: humongous object allocations should initiate marking cycles when necessary
7022456: G1: significant memory footprint increase compared to other collectors during application
7052429: G1: Avoid unnecessary scanning of humongous regions during concurrent marking
7068229: G1: Dynamically enable MT reference processing for remark pauses
7084525: G1: Generate ergonomic decision log records for young gen sizing and for pause prediction
7098085: G1: partially-young GCs not initiated under certain circumstances
7098512: G1: do not clear the next marking bitmap at the start of a Full GC
Apart from these bugs and RFEs, to achieve constant pause times in the 250–500ms range we need to avoid full GCs completely. This will most likely require a new scheme where, rather than start a full GC, we instead increase the amount of work we do gradually if we notice that we can’t keep up with the allocation rate or if fragmentation becomes an issue.