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

[David Holmes]

On 6/10/2021 4:45 am, Thomas Stuefe wrote:
> 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.

The debug code tracks all owned mutex/monitors. The _mutex_array is only 
a subset of mutex/monitors that may exist.

David

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