[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-serviceability-dev
Subject: Re: RFR(S): 8221372: Test vmTestbase/nsk/jvmti/GetThreadState/thrstat001/TestDescription.java times
From: serguei.spitsyn () oracle ! com
Date: 2019-11-26 1:47:55
Message-ID: 44c1f819-6b64-6dd8-033b-7f15413e4d82 () oracle ! com
[Download RAW message or body]
Thanks, Chris!
Serguei
On 11/25/19 4:47 PM, Chris Plummer wrote:
> Yes
>
> On 11/25/19 3:47 PM, serguei.spitsyn@oracle.com wrote:
>> Hi Chris,
>>
>> Thank you for looking at it!
>> May I count you as a reviewer?
>> My plan is to submit another mach5 100-times run before the push.
>>
>> Thanks,
>> Serguei
>>
>> On 11/25/19 12:41 PM, Chris Plummer wrote:
>>> Hi Serguei,
>>>
>>> It looks like before your fix, runs were normally just a few
>>> seconds, but there occasionally took 1 to 15 minutes, some of which
>>> result in a timeout. I looked at some of your recent results and it
>>> looks like now they are always just a few seconds, so that's a good
>>> sign that you addressed the timeout issue.
>>>
>>> Changes look good.
>>>
>>> thanks,
>>>
>>> Chris
>>>
>>> On 11/25/19 1:38 AM, serguei.spitsyn@oracle.com wrote:
>>>> Please, review a fix for test bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8221372
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8221372-jvmti-thread-state.1/
>>>>
>>>>
>>>> Summary:
>>>> The test timeouts always happen with the JFR recording and mostly
>>>> on windows.
>>>> I was not able to reproduce this with mach5 100 runs though.
>>>> However, I think the issue is with the MethodEnter/MethodExit
>>>> events that are set globally.
>>>> It is not only ~20 times slower but also impacts all JFR methods
>>>> working in background.
>>>>
>>>> The fix includes the following changes:
>>>> - the MethodEnter/MethodExit events are removed
>>>> - the code is refactored to implement repeating fragments as
>>>> functions
>>>> - minimal tracing is added to help with analysis of timeouts if
>>>> they remain
>>>>
>>>>
>>>> Testing:
>>>> Tested the vmTestbase/nsk/jvmti/GetThreadState/thrstat001 test
>>>> with mach5 100 runs.
>>>>
>>>>
>>>> Thanks,
>>>> Serguei
>>>
>>
>
[Attachment #3 (text/html)]
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Thanks, Chris!<br>
Serguei<br>
<br>
<br>
<div class="moz-cite-prefix">On 11/25/19 4:47 PM, Chris Plummer
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:5cec9b49-3fa3-410d-a86e-4427cb99867e@oracle.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix">Yes<br>
<br>
On 11/25/19 3:47 PM, <a class="moz-txt-link-abbreviated"
href="mailto:serguei.spitsyn@oracle.com"
moz-do-not-send="true">serguei.spitsyn@oracle.com</a> wrote:<br>
</div>
<blockquote type="cite"
cite="mid:d4845940-dded-b844-0228-e4804797be0c@oracle.com">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
Hi Chris,<br>
<br>
Thank you for looking at it!<br>
May I count you as a reviewer?<br>
My plan is to submit another mach5 100-times run before the
push.<br>
<br>
Thanks,<br>
Serguei<br>
<br>
<div class="moz-cite-prefix">On 11/25/19 12:41 PM, Chris Plummer
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:7508e51e-3dab-337e-0f92-13a4676810e8@oracle.com">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<div class="moz-cite-prefix">Hi Serguei,<br>
<br>
It looks like before your fix, runs were normally just a few
seconds, but there occasionally took 1 to 15 minutes, some
of which result in a timeout. I looked at some of your
recent results and it looks like now they are always just a
few seconds, so that's a good sign that you addressed the
timeout issue.<br>
<br>
Changes look good.<br>
<br>
thanks,<br>
<br>
Chris<br>
<br>
On 11/25/19 1:38 AM, <a class="moz-txt-link-abbreviated"
href="mailto:serguei.spitsyn@oracle.com"
moz-do-not-send="true">serguei.spitsyn@oracle.com</a>
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:a497e7fd-3185-8dd0-0653-c7c1cdf12f7f@oracle.com">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
Please, review a fix for test bug: <br>
<a class="moz-txt-link-freetext"
href="https://bugs.openjdk.java.net/browse/JDK-8221372"
moz-do-not-send="true">https://bugs.openjdk.java.net/browse/JDK-8221372</a><br>
<br>
<font face="Monaco">Webrev:<br>
<a class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8221372-jvmti-thread-state.1/"
moz-do-not-send="true">http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8221372-jvmti-thread-state.1/</a></font><br>
<br>
<br>
Summary:<br>
The test timeouts always happen with the JFR recording and
mostly on windows.<br>
I was not able to reproduce this with mach5 100 runs
though. <br>
However, I think the issue is with the
MethodEnter/MethodExit events that are set globally.<br>
It is not only ~20 times slower but also impacts all JFR
methods working in background.<br>
<br>
The fix includes the following changes:<br>
- the MethodEnter/MethodExit events are removed<br>
- the code is refactored to implement repeating fragments
as functions<br>
- minimal tracing is added to help with analysis of
timeouts if they remain<br>
<br>
<br>
Testing:<br>
Tested the vmTestbase/nsk/jvmti/GetThreadState/thrstat001
test with mach5 100 runs.<br>
<br>
<br>
Thanks,<br>
Serguei<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic