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

[Daniel D. Daugherty]

Just FYI...

http://mail.openjdk.java.net/pipermail/jtreg-use/2013-September/000256.html

shows how to access the test timeout factor.

There are a few tests in the repo that show code examples:

$ grep -r test.timeout.factor hotspot/jtreg
hotspot/jtreg/runtime/appcds/TestCommon.java: 
System.getProperty("test.timeout.factor", "1.0");
hotspot/jtreg/runtime/appcds/TestCommon.java: 
cmd.add("-Dtest.timeout.factor=" + timeoutFactor);
hotspot/jtreg/runtime/appcds/test-classes/ParallelLoad.java: 
Float.parseFloat(System.getProperty("test.timeout.factor", "1.0"));

Your choice on how you want to proceed.

Thumbs up from me either way.

Dan


On 10/4/18 2:48 PM, Gary Adams wrote:
> 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);
>>>>>>>>>>              }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>