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

[Gary Adams]

We currently use time factor 4 or 10 to scale up the jtreg tests.
The change I proposed was already 10x100 = 1000.
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.

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

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);
>>>>>              }
>>>>
>>>>
>>>
>>
>