RFR: 8320318: ObjectMonitor Responsible thread

[Martin Doerr]

On Wed, 29 May 2024 12:58:02 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Removed the concept of an ObjectMonitor Responsible thread.
> 
> The reason to have an ObjectMonitor Responsible thread was to avoid threads getting stranded due to a hole in the successor protocol. This hole was there because adding the necessary memory barrier was considered too expensive some 20 years ago.
> 
> The ObjectMonitor Responsible thread code adds complexity, and doing timed parks just to avoid getting stranded is not the way forward. More info about the problems with the ObjectMonitor responsible thread can be found in [JDK-8320318](https://bugs.openjdk.org/browse/JDK-8320318).
> 
> After removing the ObjectMonitor Responsible thread we see increased performance on all supported platforms except Windows. [JDK-8339730](https://bugs.openjdk.org/browse/JDK-8339730) has been created to handle this.
> 
> Passes tier1-tier7 on supported platforms.
> x64, AArch64, Riscv64, ppc64le and s390x passes ok on the test/micro/org/openjdk/bench/vm/lang/LockUnlock.java test.
> Arm32 and Zero doesn't need any changes as far as I can tell.

Works with `micro:LockUnlock` on real PPC64 hardware, too. However, we need to run more tests and also check performance.
Please note that this PR has conflicts with other changes (https://github.com/openjdk/jdk/pull/20922 and recent developments in the loom repo).

The JBS issue refers to "memory barriers (not a fence)", but you're using `StoreLoad` barriers which are nothing else than a "fence". I don't agree with the general statement that they have become significantly cheaper. That may be true for single chip designs, but not for large server systems (multi-socket). Did you run benchmarks which stress monitors on any large multi-socket system?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19454#issuecomment-2341245318