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 `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. > > The list of changes is: > - minor refactoring of the function`get_threadOop_and_JavaThread`: added an > overloaded version of this function with the extra parameter `JavaThread* > cur_thread`. It is called instead of > `JvmtiExport::cv_external_thread_to_JavaThread` from the > `VM_GetThreadListStackTraces::doit`. > - `GetSingleStackTraceClosure::do_thread()`: The use of `jt->threadObj()` is > replaced with the `JNIHandles::resolve_external_guard(_jthread)`. > - added new test to provide needed coverage: > `test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest` > > Testing: > - ran new test: > `test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest` > - TBD: tiers 1-6 (all are good) This pull request has now been integrated. Changeset: a25b7b8b Author: Serguei Spitsyn <sspit...@openjdk.org> URL: https://git.openjdk.org/jdk/commit/a25b7b8b55f2dcd3c2945193d78f754580421733 Stats: 222 lines in 5 files changed: 215 ins; 2 del; 5 mod 8295976: GetThreadListStackTraces returns wrong state for blocked VirtualThread Reviewed-by: cjplummer, amenkov ------------- PR: https://git.openjdk.org/jdk/pull/14326
