JDK-8223056 : Remove Type-Stable-Memory support for Parkers
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 13
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-04-29
  • Updated: 2021-01-28
  • Resolved: 2021-01-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
17 b07Fixed
Related Reports
Relates :  
JDK-8167108 - inconsistent handling of SR_lock can lead to crashes
Relates :  
JDK-8222518 - Remove unnecessary caching of Parker object in java.lang.Thread
Relates :  
JDK-6271298 - java.util.concurrent unpark() may reference stale native thread structures
Description
TSM for Parkers was introduced by JDK-6271298 (there's a typo in the comment in park.hpp that transposes the last 2 numbers of the bug). But since JDK-8167108 introduced Thread Safe-Memory-Reclaimation (SMR) there has been no need to issue the unpark outside the scope of the ThreadsListHandle and so no need to rely on TSM. Once we move the unpark we can remove TSM support and simplify the code.

Need to confirm that no other Parker usage has also come to rely on TSM.
Comments
Changeset: 77a43023 Author: David Holmes <dholmes@openjdk.org> Date: 2021-01-21 02:41:52 +0000 URL: https://git.openjdk.java.net/jdk/commit/77a43023
21-01-2021
It saves new/delete and reinforces that this is actually an inherent part of the JavaThread with the exact same lifecycle. There is no change to what thread.hpp imports.
14-01-2021
Why does it have to be embedded? To save a new and delete call? How large is it? thread.hpp imports way too much (and is way too big - and hard to look at in the debugger) so having a pointer out to another type of object is always my preference.
13-01-2021
The per-thread Parker instance is only accessed from two places: - Unsafe unpark() - JavaThread::interrupt The unpark code is what we are changing to ensure the parker() is only used with the scope of the TLH. JavaThread::interrupt() has three calling contexts, all of which guarantee the target is alive and guarded by a TLH: - JVM_Interrupt - JVMTI interrupt - JavaThread::send_thread_stop so there is no dependency on TSM and we can safely remove it for the Parker class. I propose to make the Parker a directly embedded object in JavaThread, rather than using the existing pointer-based mechanism.
13-01-2021