JEP 144: Reduce GC Latency for Large Heaps

Summary

Improve the performance of applications that require large heaps, of up to 32GB, by reducing garbage-collector latency.

Goals

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%.

Non-Goals

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.

Motivation

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.

Description

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.