RFR: 8273608: Deadlock when jcmd of OnError attaches to itself [v2]

[David Holmes]

On Wed, 29 Sep 2021 05:06:39 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> src/hotspot/share/runtime/mutexLocker.cpp line 396:
>> 
>>> 394:        _mutex_array[i]->unlock();
>>> 395:      }
>>> 396:   }
>> 
>> Surely we don't need this in a debug build as we already unlocked all owned locks?
>
> This logic is for release build. 
> 
> Yes, we don't need them in debug build. We should have released all owning mutexes above. 
> It's no-op in debug build because owner() should be NULL.  `thread` isn't  NULL in this function. 
> 
> Here is current bookkeeping. From a thread, we can't find all owning mutexes. @pchilano said we can try _mutex_array in release build. I think the idea is that we are supposed to capture failure in debug build. 
> 
> | class       | debug                     | release      |   |
> |-------------|---------------------------|--------------|---|
> | Thread      | _owned_locks (listedlist) | N/A          |   |
> | Mutex       | _owner                    | _owner       |   |
> | MutexLocker | _mutex_array              | _mutex_array |   |
> 
> Shall we fix _mutex_array in release? I think we can change it to GrowableArray and keep track all mutexes in runtime.

My point is that the code to process the `_mutex_array` should be in a `#else` so that we don't build it or use for debug builds. So a debug build uses `owned_locks()` while a release build uses `_mutex_array`.

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

PR: https://git.openjdk.java.net/jdk/pull/5590