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

[Xin Liu]

On Tue, 5 Oct 2021 18:17:40 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleanup: remove a statment of debugging.
>
> src/hotspot/share/utilities/vmError.cpp line 1320:
> 
>> 1318: // Otherwise, it may end up with a deadlock when dcmds try to synchronize all Java threads
>> 1319: // at safepoints.
>> 1320: bool transition_into_native() {
> 
> Since this is a highly specific workaround for one specific problem (forking off jcmd which will attach back to us with a sub command which needs a safe point) I would suggest naming this function somewhat more specific, e.g. "prepare_jcmd_workaround" or "prepare_fork_and_exec" (though the latter is misleading since this is needed only for the jcmd-attaches-to-me case).
> 
> For these cases, I also prefer the JBS issue number mentioned in a comment. Its helpful when one looks at the code, and one does not have to dig through the change history.

I don't like workaround.  I intend to do thing right.  In my understanding, fork_and_exec() is going to step into Native, isn't it?

I would like to clean up [prepare_for_emergency_dump](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp#L426) in next step. It's easier to maintain than just iterating locks manually.  that's why I would like to have a natural name.  How about `VMError::transition_java_current_to_native_from_vm()`?

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

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