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

[David Holmes]

Hi Xin,

On 13/10/2021 4:56 pm, Xin Liu wrote:
> Hi, Reviewers,
> 
> I run benchmark renaissance and strike SIGSEGV to any java threads randomly.
> 
> $java  -XX:+SafepointTimeout -XX:OnError='jcmd %p Thread.print' -jar ./renaissance-gpl-0.13.0.jar log-regression &
> $kill -11  11131 (not pid=11130, but its first java thread "main"#1, or some other java threads)
> 
> It seem that okay for both `_thread_in_Java` and `_thread_in_VM` in most cases.  However, it's not safe when the java thread was in `_thread_in_blocked`.  For instance, it was in java.lang.Runtime.gc()V+0 java.base` . It is easy to get stuck when VM state was at safepoint.

Right ... if the crash happens at a safepoint you can't reconnect to the 
VM at all.

> 
> # -XX:OnError="jcmd %p Thread.print"
> original thread state = _thread_blocked
> #   Executing /bin/sh -c "jcmd 37330 Thread.print" ...
> 37330:
> 
> 
> I just realize this is a reckless hack. we can't guarantee to avoid deadlock. We shouldn't go this way. How about we drop this?

You certainly cannot guarantee anything if you want to try and inspect 
the state of the VM that is crashing. But I thought the intent here was 
just to try and expand the set of cases where you can actually manage 
this. At the moment when you crash there are two possibilities:
- jcmd can't work no matter what you do
- jcmd could work if not for the safepoint issue

the second set of possibilities is what you are trying to enable via 
this patch. What we really have no idea of is the relative sizes of 
these two sets of circumstances. :)

Cheers,
David

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