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

[Thomas Stuefe]

On Wed, 29 Sep 2021 05:37:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> 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`.

Sorry if I missed part of the conversation, but why two different implementations? Why not use _mutex_array always? I dislike having different code in debug and release builds.

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

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