Thanks, Chris!
Serguei
On 11/25/19 4:47 PM, Chris Plummer wrote:
Yes
On 11/25/19 3:47 PM, serguei.spit...@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.spit...@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
