JDK-8224995 : java/util/concurrent/ScheduledThreadPoolExecutor/GCRetention.java timed out
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.concurrent
  • Affected Version: 13
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: windows
  • CPU: x86_64
  • Submitted: 2019-05-29
  • Updated: 2019-06-14
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
Relates :  
JDK-8141596 - java/util/concurrent/ScheduledThreadPoolExecutor/GCRetention.java starts failing intermittently
Description
...
0/100 unqueued references remaining
0/100 unqueued references remaining
0/100 unqueued references remaining
0/100 unqueued references remaining
0/100 unqueued references remaining
0/100 unqueued references remaining
0/100 unqueued references remaining
0/100 unqueued references remaining
0/100 unqueued references remaining
0/100 unqueued refe
result: Error. Agent error: java.lang.Exception: Agent 7 timed out with a timeout of 1920 seconds; check console log for any additional details
Comments
I never see any intermittent jsr166 test failures anymore. There might actually be a gc bug, keeping the last straggler weak reference from being discovered. We can make the progress message less misleading: --- src/test/jtreg/util/concurrent/ScheduledThreadPoolExecutor/GCRetention.java 21 Feb 2017 04:19:10 -0000 1.9 +++ src/test/jtreg/util/concurrent/ScheduledThreadPoolExecutor/GCRetention.java 7 Jun 2019 13:02:00 -0000 @@ -59,7 +59,7 @@ if (q.remove(1000) != null) break; System.out.printf( - "%d/%d unqueued references remaining%n", j, n); + "%d/%d unqueued references remaining%n", j + 1, n); } } }
07-06-2019
I don't think the j.u.c maintainers (hi [~martin]) can really provide any assistance here. The test timed out during an Oracle test run under Oracle test conditions.
07-06-2019
Yes, JDK-8141596 is similar but it seems that the suspected root cause was properly fixed. I don't think this is a JIT issue and therefore move this to core-libs.
07-06-2019
-- This JDK-8224995 seems can be related to old JDK-8141596 ! 'java/util/concurrent/ScheduledThreadPoolExecutor/GCRetention.java starts failing intermittently' comments extracts - "I would have to suspect that the reference to x in the creation loop: for (int i = 0; i < size; i++) { final Object x = new Object(); refs[i] = new WeakReference<Object>(x); can live longer than would appear from the code structure. I suspect the last Object created is still strongly reachable in some cases - and we may be talking 1 in 1000 runs. I don't know what exactly would impact the behaviour here." -- In the failure history for the test, along with the reported timeout case (so far only once case on 28May2019) found another single case of following crash failure on 27May2019. Error: Agent communication error: java.io.EOFException; check console log for any additional details Crash: Internal Error ...g1CollectedHeap.cpp...assert(cur_used_bytes == recal_used_bytes) failed: Used(...) is not same as recalculated used(...). Crash: V ...[libjvm.so+...] G1CollectedHeap::verify_before_full_collection(bool)+.. (not sure if this is related and could not find any related JBS issue) EDIT: above crash is for a non-standard / personal test build. From the taskid string seems possible test build of ongoing JDK-8220089 (G1 reuse survivor region as eden region at the end of gc)
07-06-2019
Looking at the test output, the problem seems to be that the last reference object is not appended to the queue by the GC. We are then endlessly calling System.gc() until we time out. I'm not sure how this can happen and unfortunately, I'm not able to reproduce this.
06-06-2019