JDK-8212084 : Implement UseGCOverheadLimit for G1
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2018-10-11
  • Updated: 2025-01-30
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Blocks :  
JDK-8212206 - Refactor AdaptiveSizePolicy to separate out code related to GC overhead
Duplicate :  
JDK-8194821 - G1 does not implement GCOverheadLimit functionality
Relates :  
JDK-8308983 - Let UseGCOverheadLimit work independently of UseAdaptiveSizePolicy in parallel GC
Description
As G1 does not instantiate the AdaptiveSizePolicy class, these JVM flags are no-ops for G1:
UseGCOverheadLimit
GCTimeLimit
GCHeapFreeLimit

UseGCOverheadLimit and tuning these flags is an effective way to prevent GC thrashing by throwing OOME early. Production users using other garbage collectors have already relied on UseGCOverheadLimit. It is desirable to make UseGCOverheadLimit also work in G1.
Comments
Unassigned myself from this RFE due to lack of time and interest. Almost all of our production applications have been using G1 for 3+ years, and we only heard perhaps 1-2 times from users asking about UseGCOverheadLimit for G1. Moreover, most applications already have mechanisms outside the JVM to detect GC thrashing, e.g. based on GarbageCollectorMXBean.getCollectionTime(), which further reduce our interest to implement this feature in the JVM.
30-01-2025
Hi Andrew, apology for the lack of progress. This feature has been a low priority for us. We have not seen cases of G1 thrashing in production, or received any user requests for this feature. However, our team have a new engineer that might be interested in working on this (and I'll help). Do you see any urgency or know anyone interested in working on this?
09-06-2020
[~manc], any update on this? Is work still ongoing?
09-06-2020
We observed that applications that migrated from CMS to G1 usually show significant reduction in pause time overhead, and G1 is much less likely to trigger full collections. Thus, applications are less likely to run into GC thrashing with G1, and UseGCOverheadLimit for G1 could be a low priority feature. From experience of UseGCOverheadLimit for CMS, user has complained that it is difficult to reach the "5 consecutive full collections" condition defined by GCOverheadLimitThreshold. By the time CMS has triggered 5 consecutive full collections, it has thrashed for quite a while, and user would prefer the JVM has terminated earlier. It is likely more difficult for G1 to reach 5 consecutive full collections. Many our services monitor the CPU overhead of GC threads as evidence for GC thrashing, which is (cpu_time_of_parallel_gc_threads + cpu_time_of_concurrent_gc_threads) / process_cpu_time. It is worth exploring if UseGCOverheadLimit for G1 could be based on CPU overhead instead of pause time overhead.
25-08-2019
As discussed in the review thread for JDK-8212206, the "develop" option AdaptiveSizePolicyGCTimeLimitThreshold (which is renamed to GCOverheadLimitThreshold) could either be removed if the default value "5" also works for G1, or be exposed to users through "experimental" or "product".
27-01-2019