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

List:       openjdk-serviceability-dev
Subject:    Re: [ping] Re: RFR 8077327: ThreadStackTrace.java throws exception: BlockedThread expected to have B
From:       "serguei.spitsyn () oracle ! com" <serguei ! spitsyn () oracle ! com>
Date:       2015-04-14 20:06:35
Message-ID: 552D734B.50802 () oracle ! com
[Download RAW message or body]

On 4/14/15 7:44 AM, Jaroslav Bachorik wrote:
> On 14.4.2015 14:37, serguei.spitsyn@oracle.com wrote:
>> On 4/14/15 12:38 AM, Daniel Fuchs wrote:
>>> Hi Jaroslav,
>>>
>>> Shouldn't you also wait for the blockedThread to be blocked on
>>> lockA at around line 252?
>>> (I mean - using Utils.waitForThreadState(blockedThread, State.BLOCKED))
>> I guess, it is about these lines:
>>
>>   255                     Utils.checkThreadState(blockedThread,
>> Thread.State.BLOCKED);
>>   256                     checkStack(blockedThread, blockedStack, 
>> bsDepth);
>>
>> The implementation of the Utils.checkThreadState() from Utils.java:
>>
>>      public static void checkThreadState(Thread t, Thread.State 
>> expected) {
>> waitForThreadState(t, expected); <=== It does the call to the
>> waitForThreadState
>>
>>          Thread.State state = 
>> tm.getThreadInfo(t.getId()).getThreadState();
>>          if (state == null) {
>>              throw new RuntimeException(t.getName() + " expected to 
>> have " +
>>                  expected + " but got null.");
>>          }
>>          if (state != expected) {
>>              t.dumpStack();
>>              throw new RuntimeException(t.getName() +
>>                   " expected to have " + expected + " but got " + 
>> state);
>>          }
>>      }
>
> Yes, that's true. On the other hand the original code did call 
> "blockedThread.waitUntilBlocked()" explicitly - so I decided to keep 
> the semantics to minimize the chance of any regressions.

That's Ok. :)

Thanks,
Serguei


>
> -JB-
>
>>
>> Thanks,
>> Serguei
>>
>>
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>> On 4/13/15 10:07 AM, Jaroslav Bachorik wrote:
>>>> On 9.4.2015 20:11, Jaroslav Bachorik wrote:
>>>>> Please, review the following test change
>>>>>
>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8077327
>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8077327/webrev.00
>>>>>
>>>>> This fix is for an intermittent failure due to timing issues. The 
>>>>> test
>>>>> is using an arbitrary waiting period to allow the tested thread to
>>>>> arrive to the requested state. Usually it works fine but under eg.
>>>>> heavy
>>>>> load this strategy will fail. The proposed solution is to explicitly
>>>>> check for the test thread arriving to the requested state instead of
>>>>> waiting eg. 10ms.
>>>>>
>>>>> I also took the liberty of removing the custom Semaphore 
>>>>> implementation
>>>>> and replacing its usage with java.util.concurrent.Phaser
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -JB-
>>>>
>>>
>>
>

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