On Thu, 8 Jun 2023 04:29:47 GMT, David Holmes <dhol...@openjdk.org> wrote:
>>> > A thread carrying a virtual thread can not be in native, blocked, parked, >>> > sleeping or waiting on some object. >> >>>A virtual thread can call native code, be blocked on an object monitor, or >>>waiting on an object monitor. Only parking and sleeping are specialized for >>>virtual threads in the list you gave. >> >> This statement was about a carrier thread (not a `JavaThread` and not a ` >> java.lang.VirtualThread`) when there is a virtual thread executed at the >> top. We are getting state bits with the >> `java_lang_Thread::get_thread_status(thread_oop)` where the `thread_oop` >> belongs to the carrier thread. But you are talking about a virtual thread >> which, of course, can be in almost any state. > > 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14366#discussion_r1222442892
