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

[Daniel D. Daugherty]

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