JDK-8371895 : Lower GCTimeLimit in TestUseGCOverheadLimit.java
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 26
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2025-11-14
  • Updated: 2025-12-23
  • Resolved: 2025-11-21
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 b26Fixed
Related Reports
Causes :  
JDK-8212084 - G1: Implement UseGCOverheadLimit
Description
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)
Comments
Fix request [25u] I backport this for parity with 25.0.3-oracle. No risk, only a test change. Clean backport. Test passes. SAP nightly testing passed.
23-12-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk25u-dev/pull/119 Date: 2025-12-21 19:03:23 +0000
21-12-2025
Changeset: eeb7c3f2 Branch: master Author: Thomas Schatzl <tschatzl@openjdk.org> Date: 2025-11-21 09:23:58 +0000 URL: https://git.openjdk.org/jdk/commit/eeb7c3f2e8e645938d9db0cf61c1d98d751f2845
21-11-2025
Also seen to fail on Windows x64
19-11-2025
[~mbaesken] Okay, there is time, let's wait like 3 more days or so.
18-11-2025
> thanks for the PR. We'll test it for a couple of days and see how stable it is with your PR added. I'll come back with an update next week. Hi [~tschatzl], so far we've seen no new failures with your PR added, probably it has helped. But maybe we should observe the situation for a couple more days.
18-11-2025
From the log you attached, it's probably better to use 80% to have some buffer. 85% should have also worked in this case. Thanks.
14-11-2025
> Can you also show the first 20 lines or so of the log? I added a jtr with the whole output of one of those failing tests. > I can decrease the failing threshold If you want to prepare a PR with such a change, I can put it into our build/test queue so that we can run in for a few days and see the results. (just doing a few runs locally is probably not so helpful because the nightly test run load would differ and as you said, the 'whole thing' is inherently dependent on performance)
14-11-2025
The tests fail on a macOS 14.5 machine with 24 cores (Apple M2 Ultra); in those test runs, we always execute the whole HS :tier1 jtreg test suite (params are -avm -conc:15 in case this is important).
14-11-2025
The log states that CPU overhead only reaches 89%, but the (default) cutoff is 98%. The test already drops it to 90% for safety. For some reason in this environment allocating data takes 200ms, which is very unusual. Maybe the test does not get cpu time (overloaded) or something? Can you also show the first 20 lines or so of the log? (The test hasn't been failing on the same platform in our CI) I can decrease the failing threshold (like 85% for the test), there is not much else I can (reasonably) do. Can you add `-XX:GCTimeLimit=85` to the `commonArgs` in the test and do a few runs?
14-11-2025
I.e. the test (and functionality) is inherently dependent on performance of the environment.
14-11-2025
Hi [~tschatzl] thanks for the PR. We'll test it for a couple of days and see how stable it is with your PR added. I'll come back with an update next week.
14-11-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/28321 Date: 2025-11-14 11:59:47 +0000
14-11-2025
Please try the PR link (that should show up in a bit).
14-11-2025