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
|
