RFR: 8273608: Deadlock when jcmd of OnError attaches to itself

[Patricio Chilano Mateo]

On Thu, 23 Sep 2021 07:26:05 GMT, Xin Liu <xliu at openjdk.org> wrote:

> hi, Reviewers,
> Thanks for the comments.
> 
> > Can you please provide a regression test for this?
> 
> yes, it should have a test. I am working on this.
> 
> > We can always walk _mutex_array like we do in print_owned_locks_on_error(). Note that locks created outside mutex_init() will not be visible though. Maybe we should fix that.
> 
> Thank Patricio for this idea. I jog down a quick scan. I would like to have Thread::owns_locks() in release build, but as you said, it's different from `Thread::owns_locks() { return owned_locks() != NULL; }`. It only covers mutex_init(). I think it should be a standalone issue.
> 
> Could you also take a look at `jfrEmergencyDump::on_vm_shutdown` in jfrEmergencyDump.cpp ?
> I think it's very similar logic. Even if we don't use RAII, I think it's still possible to have a reusable procedure.
> 
> ```
> // PreConds: 1) current != null 2) current->is_Java_Thread 3. current state is VM 4) successfully unlock all owning locks. 
> // return: true if succeed. 
> bool transition_current_to_native()
> ```
Yes, it's very similar except they need to be in _thread_in_vm initially and then switch to native. If we do reuse it maybe the wrapper should receive the state to transition to on construction to avoid that extra call to transition_current_to_native().

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

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