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. src/hotspot/share/classfile/javaClasses.hpp line 536: > 534: > 535: // additional state bits > 536: TIMED = 1 << 8, // timed parked Why handle TIMED this way instead of just making TIMED_PARKED/PARKING states? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14978#discussion_r1273010956
