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

[Xin Liu]

On Wed, 29 Sep 2021 01:16:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Xin Liu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Add a new testcase for OutOfMemoryError thrown from NIO.
>>  - Make state changer one way in VMError.
>>    
>>    Add a test to show that jcmd %p won't get stuck.
>>  - Merge branch 'master' into JDK-8273608
>>  - 8273608: Deadlock when jcmd of OnError attaches to itself
>>    
>>    Allow custom command of OnError to attach to HotSpot itself. This patch sets
>>    the thread of report_and_die() to Native before os::fork_and_exec(cmd). This
>>    prevents cmds which require safepoint synchronization from deadlock.
>>    eg. OnError='jcmd %p Thread.print'.
>
> src/hotspot/share/runtime/mutexLocker.hpp line 175:
> 
>> 173: // by fatal error handler.
>> 174: void print_owned_locks_on_error(outputStream* st);
>> 175: void unlock_locks_owned_by(Thread* t);
> 
> // Unlock all Mutex/Monitors currently owned by a JavaThread when executing
> // `OnError` actions.
> void unlock_locks_on_error(JavaThread t);

Okay. I will remove `thread->is_Watcher_thread()`.  I keep it for `prepare_for_emergency_dump`
I think the logic fits all general Thread. Can I keep `unlock_locks_on_error(Thread* t);`

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

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