RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot
David Holmes
dholmes at openjdk.org
Fri Aug 12 05:25:32 UTC 2022
On Thu, 11 Aug 2022 15:18:10 GMT, Johan Sjölén <duke at openjdk.org> wrote:
> May I please have a review for this PR which implements a `MRWMutex` class for Hotspot?
>
> This PR does 3 things:
>
> * Adds a port of ZGC's MRSW mutex (see [0]) to Hotspot
> * Adds some new utilities for writing multi-threaded tests.
> * Adds some tests for MRSW Mutex using these new utilities
>
> The ticket has some comments which might be worth checking out: https://bugs.openjdk.org/browse/JDK-8291714
>
> [0] Original source code here: https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/share/gc/z/zJNICritical.cpp
Hi Johan,
A few initial comments/queries.
Thanks.
src/hotspot/share/runtime/mrswMutex.hpp line 40:
> 38: // If a transition needs to occur when the reader or writer lock is taken (in
> 39: // case the thread blocks), then specialize on the ReaderTransition and/or
> 40: // WriterTransition parameters. This lock is unfair, high contention of readers
It is not clear why we are using template methods here to control the transition. Is this to allow use by different kinds of threads? There are AFAIK only two choices: ThreadBlockInVM for JavaThreads else nothing for other kinds of threads. ??
src/hotspot/share/runtime/mrswMutex.hpp line 45:
> 43: // current readers to proceed. The consequences are undefined if one or more
> 44: // writer threads attempt to enter their critical region when another writer
> 45: // thread already is attempting to do so or currently is in its critical region.
Are you saying that this is truly restricted to only a single thread being allowed to use this in write mode, rather than just the normal one-writer-at-a-time? Or is this simply saying the order in which multiple writers are processed is not defined?
The description should mention whether the locks are reentrant and whether a writer can downgrade to a read-lock, or implicitly take the read lock in a nested fashion; and also whether a reader can upgrade to a writelock.
src/hotspot/share/runtime/mrswMutex.hpp line 56:
> 54:
> 55: template<typename T>
> 56: class Locker : public StackObj {
Why does this need to be a template? We only use it with PlatformMonitor.
src/hotspot/share/runtime/mrswMutex.hpp line 135:
> 133: }
> 134:
> 135: // Blocked.
Blocked or locked ?
-------------
PR: https://git.openjdk.org/jdk/pull/9838
More information about the hotspot-runtime-dev
mailing list