RFR: 8295976: GetThreadListStackTraces returns wrong state for blocked VirtualThread

[David Holmes]

On Tue, 6 Jun 2023 00:50:34 GMT, Serguei Spitsyn <sspitsyn at 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