RFR: JDK-8036026: nsk/jvmti/scenarios/capability/CM02/cm02t001 fails intermittently
Gary Adams
gary.adams at oracle.com
Mon Oct 8 11:30:20 UTC 2018
Patch attached. (Added Dan as a reviewer)
Chris if you can push this, I still need patches sponsored.
To add time factor support is a much bigger task
that should be done consistently across all the
vmTestbase/nsk suite.
On 10/4/18, 3:06 PM, Daniel D. Daugherty wrote:
> 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);
>>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 8036026.patch
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20181008/383cc99e/8036026.patch>
More information about the serviceability-dev
mailing list