RFR: JDK-8036026: nsk/jvmti/scenarios/capability/CM02/cm02t001 fails intermittently

[Daniel D. Daugherty]

On 10/4/18 12:04 PM, Gary Adams wrote:
> We currently use time factor 4 or 10 to scale up the jtreg tests.
> The change I proposed was already 10x100 = 1000.

Agreed that you are already bumping it up by 10X.


> Since this is just a thread scheduling issue to let the debuggee
> run til it blocks, it should not require more time to get the
> switch to take place.

Are you really trying to say that system load doesn't affect
thread scheduling time?

> If this was a process scheduling issue, then  more complex
> coordination might be worth considering.

System load doesn't just affect process scheduling. It also
affects thread scheduling. If all the cores are busy, then
running another thread or another process is impacted.


In any case, I wasn't clear in my suggestion.

-                Thread.sleep(100);
+                Thread.sleep(100 * timeoutFactor);

assuming there is some easy way to get access to the -timeoutFactor 
parameter.

Dan



>
> On 10/4/18, 11:45 AM, Daniel D. Daugherty wrote:
>> Sleeps don't scale under load. That said, I agree with Chris that
>> the code is already in place. One possible addition is to scale
>> the sleep value by the timeout factor for the test. That will
>> further reduce the likelihood of intermittent failures.
>>
>> Dan
>>
>>
>> On 10/4/18 7:39 AM, Gary Adams wrote:
>>> Oops, wrong comment used in the patch.
>>> Fresh patch attached.
>>>
>>> On 10/4/18, 7:11 AM, Gary Adams wrote:
>>>> Patch attached.
>>>>
>>>> I think one reviewer is sufficient for a trivial patch.
>>>>
>>>> On 10/3/18, 4:49 PM, Chris Plummer wrote:
>>>>> Hi Gary,
>>>>>
>>>>> Although I don't like relying on timer delays for stuff like this, 
>>>>> the code for it is already in place, so I'm ok with making the 
>>>>> delay longer to make sure there is contention on the monitor. 
>>>>> Could you update the comment to read "// pause to provoke 
>>>>> contention on thread.endingMonitor"
>>>>>
>>>>> thanks,
>>>>>
>>>>> Chris
>>>>>
>>>>> On 10/3/18 11:55 AM, Gary Adams wrote:
>>>>>> While running a block of nsk/jvmti/scenarios tests, I noticed an 
>>>>>> occasional failure
>>>>>> for cm02t001 in windows debug platform. After enabling the nsk 
>>>>>> verbose
>>>>>> diagnostics and adding a few messages in the main test and the 
>>>>>> debuggee
>>>>>> thread, it became clear that the missing contention was due to 
>>>>>> the main thread
>>>>>> getting ahead of the debugee thread.
>>>>>>
>>>>>> The call to letFinish() below let's the deuggee thread wake up 
>>>>>> from it's wait
>>>>>> and proceed to the contention for the endingMonitor. If the main 
>>>>>> thread
>>>>>> waits a little longer it should reach the debuggee thread 
>>>>>> synchronized block.
>>>>>>
>>>>>> I reopened an earlier bug that was closed as CNR.
>>>>>>
>>>>>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8036026
>>>>>>
>>>>>>
>>>>>> diff --git 
>>>>>> a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java 
>>>>>> b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java 
>>>>>>
>>>>>> --- 
>>>>>> a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java
>>>>>> +++ 
>>>>>> b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java
>>>>>> @@ -82,7 +82,7 @@
>>>>>>                  thread.letFinish();
>>>>>>
>>>>>>                  // pause to provoke contention
>>>>>> -                Thread.sleep(100);
>>>>>> +                Thread.sleep(1000);
>>>>>>              } catch (InterruptedException e) {
>>>>>>                  throw new Failure(e);
>>>>>>              }
>>>>>
>>>>>
>>>>
>>>
>>
>