JDK-8235795 : replace monitor list mux{Acquire,Release}(&gListLock) with spin locks
  • Type: Sub-task
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 8u72,9,15
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-12-11
  • Updated: 2020-06-17
  • Resolved: 2020-02-05
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 15
15 b09Fixed
Related Reports
Blocks :  
JDK-8225631 - Consider replacing muxAcquire/Release with PlatformMonitor
Relates :  
JDK-8238370 - ObjectSynchronizer::om_release() could be simplified
Relates :  
JDK-8238766 - Perf regression on promo benchmark with 15-b9
Relates :  
JDK-8246676 - monitor list lock operations need more fencing
Relates :  
JDK-8238371 - ObjectSynchronizer::om_alloc() does not have to be public
Description
A comment from the JDK-8153224 review thread:

> Most of the comments in the CR8/v2.08/11-for-jdk14 code review cycle were
> on the monitor list changes so I'm going to take a look at extracting those
> changes into a standalone patch. Switching from Thread::muxAcquire(&gListLock)
> and Thread::muxRelease(&gListLock) to finer grained internal spin locks needs
> to be thoroughly reviewed and the best way to do that is separately from the
> Async Monitor Deflation changes. Thanks to Coleen for suggesting doing this
> extraction earlier. 

This subtask is split off from the Async Monitor Deflation project
that is tracked by JDK-8153224.
Comments
Changeset: a7a82b0c Author: Daniel D. Daugherty <dcubed@openjdk.org> Date: 2020-02-05 11:40:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a7a82b0c
07-02-2020
URL: https://hg.openjdk.java.net/jdk/jdk/rev/b353416faedf User: dcubed Date: 2020-02-05 16:41:12 +0000
05-02-2020
CR9/v2.09/12-for-jdk14 got rid of the marking abstraction and made the use of spin-locks more clear. What this subtask is about is extracting the code that replaces the gLIstLock with spin-locks into a separate patch. I thought the comment that I quoted from the CR9/v2.09/12-for-jdk14 invite was clear. Obviously it didn't do the trick. Sorry about that.
13-12-2019
I am unclear what this proposal is actually about. Does it relate to converting the "marking" to an explicit spin-lock? If a new spin-lock abstraction is introduced then we probably don't need to keep muxAcquire as well.
12-12-2019
Yup. If it looks like this bug is going to work out for pushing independently of JDK-8153224, then I'll make JDK-8225631 blocked by this bug instead of JDK-8153224.
12-12-2019
[~dcubed] Also see JDK-8225631 "Consider replacing muxAcquire/Release with PlatformMonitor" - which has stalled waiting for your async monitor deflation work to settle and get finalized.
12-12-2019