On Tue, 6 Jun 2023 00:50:34 GMT, Serguei Spitsyn <sspit...@openjdk.org> wrote:
> The `GetThreadListStackTraces` returns `JVMTI_THREAD_STATE_RUNNABLE` for a > VirtualThread blocked on a monitor when called for more than one thread. When > called for a single VirtualThread it correctly returns a state that includes > the `JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER` flag. > The `VM_GetThreadListStackTraces::doit` should call the > `get_threadOop_and_JavaThread` instead of `cv_external_thread_to_JavaThread`. > But the `get_threadOop_and_JavaThread` has a check for the current thread by > comparing with the JavaThread::current() which does not work for a `VM_op`. > Some refactoring of the `GetSingleStackTraceClosure` and > `get_threadOop_and_JavaThread` was made to make it working for a `VM_op`. > > Also, a minor bug in the `GetSingleStackTraceClosure::do_thread()` was > discovered during testing. > A minor refactoring of the `GetSingleStackTraceClosure` was made to fix the > issue. > > Also, a new test was added to provide coverage: > - `test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest` > > Testing: > - ran new test: > `test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest` > - TBD: tiers 1-6 Just a passing comment but I happened to notice today that when a virtual thread blocks on a legacy synchronization mechanism, it delegates to its carrier thread to report its state. It is not at all clear to me how this is handled at the JVMTI level. ------------- PR Review: https://git.openjdk.org/jdk/pull/14326#pullrequestreview-1464472318
