On Thu, 8 Jun 2023 04:41:10 GMT, Serguei Spitsyn <sspit...@openjdk.org> wrote:
>> Thanks for clarifying - it gets very confusing as to which "thread" is being >> talked about. But if a virtual thread is mounted on this JavaThread then I >> thought the carrier thread's thread-oop is supposed to be in a blocked state? > > It was decided with Alan that it is okay to be in a waiting state. The > `JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER` state requires a monitor to be > blocked on, so it can be confusing. Alan's comment in the original PR > [https://github.com/openjdk/jdk/pull/14298](https://github.com/openjdk/jdk/pull/14298) > was: >> if the jt is carrying thread_oop and it's okay for the JVMTI state to >> reported as WAITING when waiting for something other than Object.wait. The mental model is that the carrier is blocked so this is what an observer using the APIs should see. My recollection is that JVMTI_THREAD_STATE_WAITING was okay because there is a wriggle room in the JVM TI spec, it only uses Object.wait as an example. There may be a few rough edges to smooth down in this area. It's okay to take time with this PR and expand the tests to cover more cases and get more confident that there aren't more issues. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14366#discussion_r1222511997
