> 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
Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: simplify GetSingleStackTraceClosure, fix issue in VM_GetThreadListStackTraces::doit, improve test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14326/files - new: https://git.openjdk.org/jdk/pull/14326/files/77718470..4e794bd5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14326&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14326&range=00-01 Stats: 27 lines in 4 files changed: 11 ins; 5 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/14326.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14326/head:pull/14326 PR: https://git.openjdk.org/jdk/pull/14326
