JDK-8144727 : Timeout in Reference Processing
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Cannot Reproduce
  • Submitted: 2015-12-04
  • Updated: 2016-09-14
  • Resolved: 2016-09-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.
JDK 9
9Resolved
Related Reports
Relates :  
JDK-8077392 - Stream fork/join tasks occasionally fail to complete
Relates :  
JDK-8072777 - java/lang/ref/ReferenceEnqueuePending.java: some references aren't queued
Description
Phantom reference test may have caused VM to deadlock.
Comments
I've been trying to reproduce this issue in a variety of way, different options, different builds and different platforms without any luck. When reading the code handling reference processing I realized there had been some changes made there since the last occurrence (early February 2016, the two later matches is timeouts caused by another issue). But since I cannot reproduce even with an old build where the failure had occurred, I see no good way to continue working on this. I propose we close this one for now and re-open it if the failure occurs again.
14-09-2016
JDK-8072777 looks suspiciously similar. Some references were expected to be enqueued but seemingly weren't. [Later: Nope, that one is a bug in that test, and not related to this problem.]
12-08-2016
Looks like this is *not* caused by JDK-8077392. For that bug to be the cause, the thread that is stuck waiting in queue.remove should have a java.lang.Thread.State of BLOCKED. However, according to the jstack captured as part of the test failure, that value is WAITING. Per JDK-8077392, a BLOCKED state here indicates the notifier failed to release the lock properly, so the waiting thread starts to wake up but is unable to reacquire the lock. But a WAITING state is something else - either no notification was made or the notification was somehow lost. So back to the drawing board on this.
25-01-2016
The above characterization of JDK-8077392 as a missed notify isn't right; it's about the notifying thread failing to release the lock, which blocks a waiting thread from re-acquiring the lock on its way out of the wait. This doesn't change whether JDK-8077392 can be the underlying culprit for this failure. It doesn't matter whether the thread waiting in ReferenceQueue.remove fails to proceed due to a missed notify or because it is unable to re-obtain the lock, it still fails to proceed, ultimately resulting in the timeout.
22-01-2016
This might be an instance of JDK-8077392. That bug is about missed Java thread monitor notifications, resulting in failure of a waiting thread to wakeup. Such an occurrence would explain this failure. Specifically, we have a thread waiting in ReferenceQueue.remove for the associated phantom reference to be enqueued. If that wait missed the notification when the reference was added to the queue, the wait would never terminate and we'd see a failure that looks like this.
21-01-2016