[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR: JDK-8229829: java/lang/management/ThreadMXBean/Locks.java fails with java.lang.RuntimeExcep
From:       David Holmes <david.holmes () oracle ! com>
Date:       2020-05-14 22:56:58
Message-ID: daf035fa-1409-9335-471f-0e9a8dd2ef73 () oracle ! com
[Download RAW message or body]

+1

Thanks,
David

On 15/05/2020 6:18 am, serguei.spitsyn@oracle.com wrote:
> Hi Alex,
> 
> LGTM.
> 
> Thanks,
> Serguei
> 
> 
> On 5/14/20 11:04, Alex Menkov wrote:
>> I agree with the point.
>>
>> updated webrev (only WAITING handling is added):
>> http://cr.openjdk.java.net/~amenkov/jdk15/Locks_waiting/webrev.2/
>>
>> --alex
>>
>> On 05/13/2020 19:20, David Holmes wrote:
>>> Hi Alex,
>>>
>>> On 14/05/2020 10:55 am, Alex Menkov wrote:
>>>> Hi all,
>>>>
>>>> Please review the fix for
>>>> https://bugs.openjdk.java.net/browse/JDK-8229829
>>>> webrev:
>>>> http://cr.openjdk.java.net/~amenkov/jdk15/Locks_waiting/webrev/
>>>>
>>>> The fix adds handling for WAITING
>>>
>>> That part is good.
>>>
>>>> (and for consistency TIMED_WAITING 
>>>
>>> But this could be a problem. I know what your intent is but we are 
>>> waiting to observe a thread transition to a state that it can't 
>>> escape from, but with TIMED_WAITING the thread can escape - when the 
>>> timeout elapses. So it is possible that the target becomes 
>>> TIMED_WAITING before you check the state, but then leaves that state 
>>> due to timeout, and then you check the state and will loop until you 
>>> trigger a failure.
>>>
>>> Cheers,
>>> David
>>> -----
>>>
>>>> which is not used in the test) states as it has for BLOCKED state.
>>>>
>>>> --alex
> 
[prev in list] [next in list] [prev in thread] [next in thread]