JDK-8253694 : Remove Thread::muxAcquire() from ThreadCrashProtection()
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 16
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-09-28
  • Updated: 2020-10-22
  • Resolved: 2020-10-06
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 16
16 b19Fixed
Related Reports
Relates :  
JDK-8225631 - Consider replacing muxAcquire/Release with PlatformMonitor
Description
Current ThreadCrashProtection() implementation uses static members which requires the use of Thread::muxAcquire() to allow only one user at a time.  We can avoid this synchronization requirement if each thread has its own ThreadCrashProtection* data.
Comments
Changeset: 57493c19 Author: Patricio Chilano Mateo <pchilanomate@openjdk.org> Date: 2020-10-06 14:48:56 +0000 URL: https://git.openjdk.java.net/jdk/commit/57493c19
06-10-2020
I was sure there was another case but it no longer seems to exist. I'm also having trouble recalling how the gInflationLock actually works.
28-09-2020
[~dholmes] Yes. And I actually only see one other user of muxAcquire/Release: the call in read_stable_mark() ( which I'm having a hard time understanding why we need it since the inflation process after we CAS a markWord::INFLATING() value shouldn't take that long and we are already using park() calls if we spin too much anyways).
28-09-2020
This would also simplify JDK-8225631. :)
28-09-2020