On Fri, 21 Jul 2023 18:01:45 GMT, Alan Bateman <al...@openjdk.org> 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