> 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 two additional 
commits since the last revision:

 - fixed typo in a comment in jvmtiEnvBase.cpp
 - nit: restored one comment as was before

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14326/files
  - new: https://git.openjdk.org/jdk/pull/14326/files/4e794bd5..d20e1221

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14326&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14326&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 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

Reply via email to