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

[Gary Adams]

fyi - I think JDK-8201603 tc02t001 is suffering from the same issue.
A sleep(100) is used to provoke a contention with the debuggee thread.
If the debuggee is not scheduled quickly enough, the main thread proceeds
to release the contended object M and the test fails because not all the 
contended
conditions were reported event.

On 10/4/18, 1:03 PM, Daniel D. Daugherty wrote:
> On 10/4/18 1:00 PM, Gary Adams wrote:
>> On 10/4/18, 12:13 PM, Daniel D. Daugherty wrote:
>>> 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?
>> In this particular test, the main thread and the debuggee thread
>> are toggling back and forth around several monitors and
>> synchronized code blocks. Not sure the tests are written
>> for an arbitrarily high system load.
>>>
>>>> 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.
>> Currently, timeoutFactor has not been introduced to the vmTestbase/nsk
>> test suite.
>
> Ummmm.... The -timeoutFactor parameter comes with JavaTest/JTREG
> so it is already supported in the test harness that is uses to
> run the vmTestbase/nsk test suite... What am I missing here?
>
> Dan
>
>
>>>
>>> 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);
>>>>>>>>>              }
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>