JDK-8212084 : G1: Implement UseGCOverheadLimit
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-10-11
  • Updated: 2025-12-19
  • Resolved: 2025-10-27
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.
JDK 17 JDK 21 JDK 25 JDK 26
17.0.19-oracleFixed 21.0.11-oracleFixed 25.0.3-oracleFixed 26 b22Fixed
Related Reports
Blocks :  
JDK-8370325 - G1: Disallow GC for TLAB allocation
Blocks :  
JDK-8212206 - Refactor AdaptiveSizePolicy to separate out code related to GC overhead
Causes :  
JDK-8371895 - Lower GCTimeLimit in TestUseGCOverheadLimit.java
Duplicate :  
JDK-8194821 - G1 does not implement GCOverheadLimit functionality
Relates :  
JDK-8308983 - Let UseGCOverheadLimit work independently of UseAdaptiveSizePolicy in parallel GC
Sub Tasks
JDK-8370491 :  
Release Note: G1: Support UseGCOverheadLimit - Resolved
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
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk25u-dev/pull/74 Date: 2025-12-10 12:18:03 +0000
11-12-2025
Fix request [25u] I backport this for parity with 25.0.3-oracle. Rather simple improvement implementing a feature on G1 already known for other GCs. But as it might alter GC behavior there is a certain risk for applications that depend on the old behavior. Needed various adaptions. Test passes. SAP nightly testing passed.
11-12-2025
No problem. We in the gc team will typically find duplicates during triage. Obviously a cursory search for existing bugs helps avoiding filing duplicates. We would also link any follow-up issues to this issue, so typically these follow-ups should be easy to find from this issue, particularly if it's a recently fixed issue (but yes, we make mistakes and overlook them :) But the chance of overlooking a new comment to a closed issue is very high; purely by chance a colleague has been looking at it just now)
14-11-2025
> Please do not add to closed issues, but file new ones. Sure no problem, I thought about filing a new issue too, but first wanted to find out a) is there maybe already an issue and b) is it maybe something bad on the test machine we use. But thanks for filing the new issue.
14-11-2025
[~mbaesken]: Please do not add to closed issues, but file new ones. I filed JDK-8371895 this time.
14-11-2025
gc/TestUseGCOverheadLimit.java#G1 fails in our test infrastructure sometimes on macOS aarch64 (9 failure have been seen so far). end of log of an example failure : .... [46.311s][info ][gc] GC(686) Pause Young (Concurrent Start) (G1 Evacuation Pause) (Evacuation Failure: Allocation) 127M->127M(128M) 14.228ms [46.311s][debug][gc] GC Overhead Limit: GC Time 89.488501 Free Space 0.000000 Counter 0 [46.311s][info ][gc] GC(688) Concurrent Mark Cycle [46.313s][debug][gc] GC(687) Clear Bitmap 1.994ms [46.484s][info ][gc] GC(687) Pause Full (G1 Compaction Pause) 127M->121M(128M) 173.420ms [46.484s][info ][gc] GC(688) Concurrent Mark Cycle 173.609ms [46.519s][debug][gc] GC(689) Allocated 0 survivor 0 old percent total 0.00% (10%) [46.519s][info ][gc] GC(689) Pause Young (Normal) (G1 Evacuation Pause) (Evacuation Failure: Allocation) 127M->127M(128M) 33.855ms [46.519s][debug][gc] GC Overhead Limit: GC Time 89.862385 Free Space 0.000000 Counter 0 [46.744s][info ][gc] GC(690) Pause Full (G1 Compaction Pause) 127M->121M(128M) 225.117ms [46.769s][debug][gc] GC(691) Allocated 0 survivor 0 old percent total 0.00% (10%) [46.769s][info ][gc] GC(691) Pause Young (Concurrent Start) (G1 Evacuation Pause) (Evacuation Failure: Allocation) 127M->127M(128M) 23.232ms [46.769s][debug][gc] GC Overhead Limit: GC Time 89.725280 Free Space 0.000000 Counter 0 [46.769s][info ][gc] GC(693) Concurrent Mark Cycle [46.770s][debug][gc] GC(692) Clear Bitmap 0.723ms [46.968s][info ][gc] GC(692) Pause Full (G1 Compaction Pause) 127M->121M(128M) 199.113ms [46.968s][info ][gc] GC(693) Concurrent Mark Cycle 199.256ms [Ljava.lang.Object;@3d012ddd ]; stderr: [] exitValue = 0 java.lang.RuntimeException: Unexpected to get exit value of [0] at jdk.test.lib.process.OutputAnalyzer.shouldNotHaveExitValue(OutputAnalyzer.java:563) at gc.TestUseGCOverheadLimit.main(TestUseGCOverheadLimit.java:77) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) at java.base/java.lang.Thread.run(Thread.java:1474)
14-11-2025
Changeset: 3d2ce804 Branch: master Author: Thomas Schatzl <tschatzl@openjdk.org> Date: 2025-10-27 06:53:08 +0000 URL: https://git.openjdk.org/jdk/commit/3d2ce8045f9ea52c6559638f9cc7e0a0544b4540
27-10-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/27950 Date: 2025-10-23 07:11:16 +0000
23-10-2025
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