On Wed, 26 Jul 2023 09:42:10 GMT, Serguei Spitsyn <sspit...@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.

I can't see why it would be needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14978#discussion_r1274874943

Reply via email to