On Tue, 19 Sep 2023 10:35:33 GMT, Alan Bateman 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
>>
> 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
>
On Thu, 14 Sep 2023 13:30:28 GMT, Alan Bateman 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
>>
On Mon, 18 Sep 2023 01:44:10 GMT, David Holmes wrote:
> Surely that is not a specified exported thread state though ?? Why would we
> care about PINNED (timed or otherwise) in the current context?
There are internal states and then mappings to the thread states defined by the
APIs
On Fri, 15 Sep 2023 06:34:52 GMT, Alan Bateman wrote:
>> What is TIMED PINNING?
>>
>> To me TIMED_X are a specific set of states and there are not enough of them
>> to consider TIMED to be a bit that can be applied to any state X.
>
>> What is TIMED PINNING?
>
> LockSupport.parkNanos when
On Fri, 15 Sep 2023 00:36:10 GMT, David Holmes wrote:
> What is TIMED PINNING?
LockSupport.parkNanos when the carrier can't be released due to monitor or
native frame.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/14978#discussion_r1326860516
On Thu, 14 Sep 2023 13:29:48 GMT, Alan Bateman wrote:
>> Yes but TIMED and SUSPENDED are not alike. I assume SUSPENDED is a
>> stand-alone bit because you can be in various states and suspended at the
>> same time. But TIMED isn't like that.
>
>> Yes but TIMED and SUSPENDED are not alike. I
On Thu, 27 Jul 2023 01:54:58 GMT, Serguei Spitsyn wrote:
> Looks good.
> Thanks,
> Serguei
Thanks Serguei. I had to pause this to work on other things. When I sync'ed up
the branch I found I had to update recently introduced test
jvmti/vthread/VThreadEventTest/VThreadEventTest.java as it was
On Wed, 26 Jul 2023 12:18:02 GMT, David Holmes wrote:
> Yes but TIMED and SUSPENDED are not alike. I assume SUSPENDED is a
> stand-alone bit because you can be in various states and suspended at the
> same time. But TIMED isn't like that.
The SUSPENDED bit can only be set when the virtual
> 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
>
> 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
>
On Thu, 27 Jul 2023 01:30:01 GMT, Serguei Spitsyn wrote:
> Nit: normal indent for native code is 2.
The .c files I sampled in test/hotspot/jtreg/serviceability/jvmti/** used 4,
either is okay as this is just two tiny JNI functions.
-
PR Review Comment:
On Fri, 21 Jul 2023 18:01:45 GMT, Alan Bateman 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
>
On Fri, 21 Jul 2023 18:01:45 GMT, Alan Bateman 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
>
On Wed, 26 Jul 2023 17:38:24 GMT, Alan Bateman wrote:
>> I can't see why it would be needed.
>
>> It would be nice to add a short comment why this is needed.
>
> It's not needed here, it was needed in another version of the tests. While
> benign, I can remove it to avoid any confusion. Thanks.
On Wed, 26 Jul 2023 12:20:49 GMT, David Holmes wrote:
>> test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java
>> line 133:
>>
>>> 131: } finally {
>>> 132: thread.join();
>>> 133: Reference.reachabilityFence(lock);
>>
>> It
On Wed, 26 Jul 2023 09:42:10 GMT, Serguei Spitsyn 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
On Tue, 25 Jul 2023 05:50:12 GMT, Alan Bateman wrote:
>> 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
On Fri, 21 Jul 2023 18:01:45 GMT, Alan Bateman 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
>
On Tue, 25 Jul 2023 05:21:45 GMT, David Holmes wrote:
> Why handle TIMED this way instead of just making TIMED_PARKED/PARKING states?
Been there but it is 3 additional states and a lot simpler to just use the
additional state bits, like we do with SUSPENDED. We might use another one for
On Fri, 21 Jul 2023 18:01:45 GMT, Alan Bateman 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
>
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
22 matches
Mail list logo
