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

[Kim Barrett]

On Wed, 17 Aug 2022 13:00:57 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/mrswMutex.hpp line 63:
>> 
>>> 61:     Locker(T* lock)
>>> 62:       : _lock(lock) {
>>> 63:       if (_lock != nullptr) {
>> 
>> When would it ever make sense for the `lock` argument to be nullptr?  Instead assert in the constructor that it is not?
>
> It would make sense in the same circumstances the MutexLocker also takes a NULL argument.

I'm going to claim that MutexLocker with a nullptr argument is a mistake,
making it much harder to understand code that does that (or might do that, who
knows, there's nothing in the source code to suggest one way or the other).

My recollection when looking at this with Coleen a long time ago was that
there are some tiny number of places that were doing that. Reasons included
(1) called really early (before threads and mutexes are initialized), (2)
weird (and possibly broken) things where the VMThread (thinks it) needs to
ignore a lock, or (3) recursion. Making those few unusual cases look textually
identical to the usual case is not very helpful, IMO. Coleen says "At one
point I thought we'd squashed the null arguments to MutexLocker. We should do
that."

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

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