Details
-
Sub-task
-
Resolution: Fixed
-
P4
-
8u72, 9, 15
-
b09
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 byJDK-8153224.
> 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
Attachments
Issue Links
- blocks
-
JDK-8225631 Consider replacing muxAcquire/Release with PlatformMonitor
- Resolved
- relates to
-
JDK-8238370 ObjectSynchronizer::om_release() could be simplified
- Resolved
-
JDK-8238371 ObjectSynchronizer::om_alloc() does not have to be public
- Resolved
-
JDK-8246676 monitor list lock operations need more fencing
- Resolved
-
JDK-8238766 Perf regression on promo benchmark with 15-b9
- Closed
- links to
-
Commit openjdk/panama-foreign/a7a82b0c
(1 links to)