RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot [v5]

[Thomas Stuefe]

On Mon, 29 Aug 2022 08:47:31 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
>
> Johan Sjölén has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

> People want:
> 
> 1. Nullable threads
> 2. PlatformMonitor
> 3. Monitor
> 4. won't work with 1., as it requires a `Thread` thread, so that will require two different ReadWriteLocks (or method impls).
> 
> When we pick 3. we also have to make a decision on whether to support waiting without safepoints or not, making the behavior of ReadWriteLock a bit more complicated and perhaps opaque. Developers reading the code using this lock should preferably know what it does and what the implications are of using it.
> 
> The right answer is probably to make a `PlatformReadWriteLock` and a `ReadWriteLock`, going with convention here.
> 
> So there are a lot of different choices to be made here. On top of that we have the actual implementation, whose issues are yet to be revealed to us.
> 
> I'd like to quote David Holmes here:
> 
> > Whether this RWL implementation will turn out to be useful for any existing subsystems without exhibiting performance pathologies or bad interactions with existing synchronization code is just something we will have to see. However, as we tend not to encourage unused code it would perhaps be better to delay integration of this until there is an _actual usecase ready for it_.
> 
> I have a use case for this in UL. This is the use case which I will develop this patch towards. If new use cases arises, then patches can be made to this code to supply more use cases.

My use case is for the NMT malloc site table, which gives us the same restrictions as UL (being pre-init-able).

Note that even if you move UL initialization up, UL should still work without Thread==NULL in my opinion, since logging is one of the things that should work ideally always.

BTW, I am trying to get this: https://github.com/openjdk/jdk/pull/10178 into JDK, which may give you an easy option to test the mark with Thread==NULL in gtests.

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

PR: https://git.openjdk.org/jdk/pull/9838