On Fri, 21 Jul 2023 18:01:45 GMT, Alan Bateman <[email protected]> wrote:
> Thread::getState is an API for monitoring and management purposes to report
> the thread state. If a virtual thread is parked with LockSupport.parkNanos,
> its state is reported as WAITING when it should be TIMED_WAITING. JVM TI
> GetThreadState has the same issue in that it returns
> JVMTI_THREAD_STATE_WAITING_INDEFINITELY instead of the
> JVMTI_THREAD_STATE_WAITING_WITH_TIMEOUT bit set. Not a very visible issue
> because JDWP maps both states to "WAIT" but it may be noticed by tools using
> other JVM TI agents.
>
> The change is straight-forward, it's just additional state bit to indicate
> that park is timed. The existing virtual/ThreadAPI.java test is expanded to
> this scenario. A new test is added for JVM TI GetThreadState to test
> waiting/timed-waited cases (including pinned) as test coverage seems patchy
> here.
test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java
line 133:
> 131: } finally {
> 132: thread.join();
> 133: Reference.reachabilityFence(lock);
It would be nice to add a short comment why this is needed.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/14978#discussion_r1274681311
