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

[David Holmes]

On Fri, 19 Aug 2022 15:52:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I've gotten more push-back on things called blah_locked(). The motivation was that it's not clear if it is the caller or callee who should take the lock, so that name convention isn't really helping the reader. I'm a but sympathetic to that point-of-view.
>> 
>> I still don't think this is something we should be squashing. Maybe it would help sway me if someone tried to convert ZActivatedArray and show what the code would look like if we couldn't use this pattern:
>> https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/share/gc/z/zArray.inline.hpp
>> 
>> Alternatively, we could have two versions of lockers to appease both sides? One that never accepts nullptr, which would be the locker that most should be using, and one for those cases where we do need to run with and without the lock held.
>
> I don't now if your zlock is even a standard runtime/mutex, but let's definitely not have another version of lockers.  I've never pushed back on blah_locked().  I need to see more evidence of why we need null mutex in the code (after the sweeper is removed), before I suggest a policy change.
> I have a patch that removes the NULL ObjectLocker argument. I thought ObjectLocker was the only thing that took null until yesterday.

> Alternatively, we could have two versions of lockers to appease both sides?

"They who cannot remember the past are condemned to repeat it." :)

We used to have `MutexLockerEx` that allowed the NULL whereas `MutexLocker` did not. 

I have no issues with the NULL case as it is cleaner that defining locked and unlocked code paths.

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

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