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

[David Holmes]

On Thu, 8 Sep 2022 16:13:17 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>>To be clear, you will only ever get a null if someone passes it in explicitly as Thread::current_or_null() should never be able to return null in the contexts you would use this RWL.
>> 
>> Context: UL uses static initialization for LogTagSets, these use the RWLock and as such our thread system isn't initialized yet. It's not strictly necessary, as we can re-write things to not require this.
>> 
>> Edit: Perhaps the right decision is to simply delay the initialization of LogTagSets.
>
>> >To be clear, you will only ever get a null if someone passes it in explicitly as Thread::current_or_null() should never be able to return null in the contexts you would use this RWL.
>> 
>> 
>> 
>> Context: UL uses static initialization for LogTagSets, these use the RWLock and as such our thread system isn't initialized yet. It's not strictly necessary, as we can re-write things to not require this.
>> 
>> 
>> 
>> Edit: Perhaps the right decision is to simply delay the initialization of LogTagSets.
> 
> The early initialization of UL at lib load time is certainly a pain. 
> 
> But there are other things too, other code running before initialisation, and then there is the case of non-attached threads and signal handling, etc.
> 
> I would be happy if this primitive was usable with Thread.current == Null. Otherwise you limit the future usefulness, and whatever code people use this lock in will also not be usable in these corner cases. 
> 
> If it does not cost too much complexity.

Any use by non-attached threads is potentially problematic as they can prevent safepoints etc. I don't think we should be using a RWL in any code that might be executed by a non-attached thread. None of our locking code is async-signal-safe so using it from signal handlers should also be avoided.

Early initialization of UL should be examined more closely. Anything initialized before we have threads doesn't need locking by definition, so if we structure the code/api correctly we won't encounter locks. That may mean clearly separating initialization code from similar modification code e.g. a growable data structure will need a lock in the grow method, but we don't then use the grow method from the constructor.

But lets see what @jdksjolen comes up with here.

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

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