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

[Coleen Phillimore]

On Fri, 19 Aug 2022 15:35:34 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> You can have a blah_locked() version in these cases.  Having code called in multiple situations (some paths locked and some not) might be not great.  Some higher level of code should have done the locking or not.
>> That said, the sweeper has multiple of these with the Compile_lock so this can't be attempted to be squashed until the sweeper is gone.
>
> 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.

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

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