JDK-8270337 : New Thread cannot park when reusing an earlier Thread's Parker whose _counter is not zero
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: openjdk8u292,11.0.11
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: generic
  • CPU: generic
  • Submitted: 2021-07-13
  • Updated: 2021-08-03
  • Resolved: 2021-08-03
Related Reports
Relates :  
JDK-8167108 - inconsistent handling of SR_lock can lead to crashes
Description
Submit on hehalf of miao zheng.

In attached test Parker.java, two threads are created, second thread is created after first thread join and finish. 

In jdk18, the second thread is parked. In jdk8 and jdk11, the second thread is not parked, it will just go ahead and print the log "^^^^^^:  testPark12 running here".

Behavior should be same for jdk8/11 and lasted jdk18.

The problem is in jdk8/11 Parker::Allocate and Parker::Release. There is a free list of parker, and when the first thread exit, it releases the parker to the free list. Before the parker release to the free list, the _counter of Parker should be reset. 

In jdk18, https://bugs.openjdk.java.net/browse/JDK-8223056 removes the free list of parker, and each thread has its own parker, so this problem is solved.

Not sure backport entier https://bugs.openjdk.java.net/browse/JDK-8223056. Or keep parker freelist mechanism, only reset _counter when release.
Comments
Thread-SMR was added to JDK 10 under JDK-8167108.
14-07-2021
In the current code threads are never deleted while they are in use, even if they have logically terminated. This is done via the Thread-SMR (safe-memory-reclaimation) changes and use of a ThreadsListHandle. Hence you can never access a free'd Parker. Hence we were able to get rid of the TSM (type-stable-memory) freelist implementation. Spurious unparks are allowed as per the unpark() specification, but they are no longer possible via the internal VM implementation.
14-07-2021
[~dholmes] Thanks David! Found an early related which is closed as not an issue, JDK-6447639. The argument was "An unpark call may actually be logically directed to some long-dead thread. (The fact that this can occur at all was the reason for keeping parker free lists; without them, these stray calls wrote into free'd memory.) Thus, surprising wake-ups remain possible even if you clear count, which is why the code doesn't bother to do so.��� But in lastest implementation after JDK-8223056, Parker object is free and destruct when destruct JavaThread, unpark long-dead thread will write into free'd memory.
14-07-2021
Strictly speaking this is not a bug as LockSupport.park() is allowed to return spuriously so the test program can show either behaviour and still be correct. So changing this issue to an Enhancement request. The fact this is not actually a bug is probably why it has never been noticed. You can get at most one spurious unpark. If I were an 8u or 11u maintainer I'd be tempted to just close this long standing quirk as "Will not fix". I certainly would not recommend back-porting the freelist removal logic.
13-07-2021