Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8135609 | emb-9 | David Holmes | P4 | Resolved | Fixed | team |
The workaround triggered by WorkAroundNPTLTimedWaitHang (an experimental flag set to 1 by default) was to alleviate a hang that could occur on a pthread_cond_timedwait on LInux, if the timeout value was a time in the past - see JDK-6314875. This glibc bug was fixed in 2005 in glibc 2.3.5-3
https://lists.debian.org/debian-glibc/2005/08/msg00201.html
but the workaround persists and was (unfortunately) copied into the BSD and AIX ports.
It is time to remove that workaround but before we can do that we need to be sure that we are not in fact hitting the workaround code. To that end I propose to use this bug to switch the flag's value to 0 to verify correct operation.
If that goes well then we can remove the code either later in JDK 9 or early in JDK 10.
https://lists.debian.org/debian-glibc/2005/08/msg00201.html
but the workaround persists and was (unfortunately) copied into the BSD and AIX ports.
It is time to remove that workaround but before we can do that we need to be sure that we are not in fact hitting the workaround code. To that end I propose to use this bug to switch the flag's value to 0 to verify correct operation.
If that goes well then we can remove the code either later in JDK 9 or early in JDK 10.
- backported by
-
JDK-8135609 Disable WorkAroundNPTLTimedWaitHang by default
- Resolved
- relates to
-
JDK-8133231 Mark TimeoutLockLoops.java as failing intermittently
- Closed
-
JDK-8145725 Remove the WorkAroundNPTLTimedWaitHang workaround
- Resolved
-
JDK-6314875 Linux NPTL/Futex pthread_cond_timedwait() bug can corrupt condvar & hang - impacts JVM object.wait()
- Closed
-
JDK-8029453 java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java failed by timeout
- Closed