Re: Fwd: Re: RFR: 8062536: [TESTBUG] Conflicting GC combinations in jdk tests
Hi Evgeniya,
On 2014-11-12 17:07, Evgeniya Stepanova wrote:
Hi Bengt,
Please see comments inline
On 12.11.2014 19:43, Bengt Rutisson wrote:
On 2014-11-12 16:21, Evgeniya Stepanova wrote:
Hi everyone!
Since the decision was made to change only tests which fail because
of conflict for now (skip selfish tests), I post new webrev for
jdk part of the JDK-8019361
https://bugs.openjdk.java.net/browse/JDK-8019361:
http://cr.openjdk.java.net/~avstepan/eistepan/8062536/webrev.03/
Thanks for updating the webrev!
A couple of comments:
MemoryTestAllGC.sh
The test is run three times, once with no params, once with
ParallelGC and once with CMS. So, I think the @requires should just
be vm.gc == null. Similarly to what was done for PendingAllGC.sh.
The third run (with CMS) is commented. Without this run UseParallelGC
is valid option
#runOne -XX:+UseConcMarkSweepGC MemoryTest 3
(http://cr.openjdk.java.net/~avstepan/eistepan/8062536/webrev.03/test/java/lang/management/MemoryMXBean/MemoryTestAllGC.sh.frames.html)
Right. I missed that it was commented out. Thanks for pointing that out.
I went back and checked. That line was already commented out when the
test was first added in 2001. Do you mind removing the CMS line to avoid
more people doing the same mistake that I did? I don't think we need to
keep a commented out test around for more than 13 years... ;)
TestInputArgument.sh
The changes here seem unrelated to @requires.
This test was changed after conversation with David Holmes (see
thread below)
Ok. Good.
EnqueuePollRace.java
Can you explain why it is safe to remove -XX:+UseSerialGC for this test?
This test was modified after conversation with Filipp Zhinkin and
Mandy Chung (https://bugs.openjdk.java.net/browse/JDK-8051723)
Ok.
JpsHelper.java
Can you explain why it is safe to remvoe -XX:+UseParallelGC for this
test?
This test was changed after conversation with Katja Kantserova (see
thread below), GC flag is just an arbitrary chosen test flag
Ok.
I should clearly have read the other reviews more.
In that case I guess the changes look good from my perspective.
Thanks,
Bengt
When I use Aurora to check what tests that currently are considered
known because of JDK-8019361 I get a pretty long list:
http://aurora.ru.oracle.com/functional/faces/CRRules.xhtml?cr=JDK-8019361
Are the tests in webrev.03 the only tests that still fail? Have the
others been fixed in other ways?
There would be 2 more changes in reviews in closed part :)
Thanks,
Evgeniya Stepanova
Thanks,
Bengt
Thanks,
Evgeniya Stepanova
On 07.11.2014 15:34, Evgeniya Stepanova wrote:
David, Filipp, Katja
Diff have been updated one more time:
java/lang/management/RuntimeMXBean/TestInputArgument.sh and
test/java/lang/ref/EnqueuePollRace.java have been changed
http://cr.openjdk.java.net/~eistepan/8062536/webrev.02/
Thanks
On 07.11.2014 9:37, David Holmes wrote:
On 7/11/2014 12:36 AM, Evgeniya Stepanova wrote:
New webrev:
http://cr.openjdk.java.net/~eistepan/8062536/webrev.01/
In:
test/java/lang/management/RuntimeMXBean/TestInputArgument.sh
the use of the gc options seems incidental - it's just picking two
innocuous options to use - similar to the JpsHelper case. You
could replace +UseParallelGC with something like
+UseFastJNIAccessors (platform independent and normally true).
David
-
Thanks,
Evgeniya Stepanova
On 06.11.2014 17:35, Yekaterina Kantserova wrote:
Thanks a lot!
On 11/06/2014 02:05 PM, Evgeniya Stepanova wrote:
Hi Katja,
Ok, this seems to be a perfect solution. Thank you. I'll change
the
diff accordingly.
Thanks,
Evgeniya Stepanova
On 06.11.2014 16:56, Yekaterina Kantserova wrote:
Hi Dima,
On 11/06/2014 11:22 AM, Dmitry Fazunenko wrote:
Hi Katja,
You are right, there will be no conflict, because test
ignores any
external VM flags.
So, adding @requires seems unnecessary here, but...
Ignoring external options is bad thing, such selfish tests are
not applicable for other areas, like GC, compiler, RT.
This particular case is to test the defined flags are shown up as
expected.
Evgeniya,
would you mind to change JpsHelper.java instead?
+++ b/test/sun/tools/jps/JpsHelper.java
@@ -93,7 +93,7 @@
/**
* VM arguments to start test application with
*/
-public static final String[] VM_ARGS = {-Xmx512m,
-XX:+UseParallelGC};
+public static final String[] VM_ARGS = {-Xmx512m,
-XX:+PrintGCDetails};
/**
* VM flag to start test application with
*/
Best regards,
Katja
@requires will allow to modify tests to include external vm
options without any risk of bumping into conflict and extend
area
of test applicability.
But if you still believe, that @requires is not necessary - it's
not a problem, tests could be kept as is.
Thanks,
Dima
On 06.11.2014 16:27, Yekaterina Kantserova wrote:
Hi Evgeniya,
As David has pointed out these jps tests are not testing gc.
The
-XX:+UseParallelGC is just an arbitrary chosen
Re: Fwd: Re: RFR: 8062536: [TESTBUG] Conflicting GC combinations in jdk tests
Hi Bengt!
Ok, I'll remove this string.
Thank you for reviewing it one more time :)
Evgeniya Stepanova
On 13.11.2014 13:44, Bengt Rutisson wrote:
Hi Evgeniya,
On 2014-11-12 17:07, Evgeniya Stepanova wrote:
Hi Bengt,
Please see comments inline
On 12.11.2014 19:43, Bengt Rutisson wrote:
On 2014-11-12 16:21, Evgeniya Stepanova wrote:
Hi everyone!
Since the decision was made to change only tests which fail because
of conflict for now (skip selfish tests), I post new webrev for
jdk part of the JDK-8019361
https://bugs.openjdk.java.net/browse/JDK-8019361:
http://cr.openjdk.java.net/~avstepan/eistepan/8062536/webrev.03/
Thanks for updating the webrev!
A couple of comments:
MemoryTestAllGC.sh
The test is run three times, once with no params, once with
ParallelGC and once with CMS. So, I think the @requires should just
be vm.gc == null. Similarly to what was done for PendingAllGC.sh.
The third run (with CMS) is commented. Without this run UseParallelGC
is valid option
#runOne -XX:+UseConcMarkSweepGC MemoryTest 3
(http://cr.openjdk.java.net/~avstepan/eistepan/8062536/webrev.03/test/java/lang/management/MemoryMXBean/MemoryTestAllGC.sh.frames.html)
Right. I missed that it was commented out. Thanks for pointing that out.
I went back and checked. That line was already commented out when the
test was first added in 2001. Do you mind removing the CMS line to
avoid more people doing the same mistake that I did? I don't think we
need to keep a commented out test around for more than 13 years... ;)
TestInputArgument.sh
The changes here seem unrelated to @requires.
This test was changed after conversation with David Holmes (see
thread below)
Ok. Good.
EnqueuePollRace.java
Can you explain why it is safe to remove -XX:+UseSerialGC for this test?
This test was modified after conversation with Filipp Zhinkin and
Mandy Chung (https://bugs.openjdk.java.net/browse/JDK-8051723)
Ok.
JpsHelper.java
Can you explain why it is safe to remvoe -XX:+UseParallelGC for this
test?
This test was changed after conversation with Katja Kantserova (see
thread below), GC flag is just an arbitrary chosen test flag
Ok.
I should clearly have read the other reviews more.
In that case I guess the changes look good from my perspective.
Thanks,
Bengt
When I use Aurora to check what tests that currently are considered
known because of JDK-8019361 I get a pretty long list:
http://aurora.ru.oracle.com/functional/faces/CRRules.xhtml?cr=JDK-8019361
Are the tests in webrev.03 the only tests that still fail? Have the
others been fixed in other ways?
There would be 2 more changes in reviews in closed part :)
Thanks,
Evgeniya Stepanova
Thanks,
Bengt
Thanks,
Evgeniya Stepanova
On 07.11.2014 15:34, Evgeniya Stepanova wrote:
David, Filipp, Katja
Diff have been updated one more time:
java/lang/management/RuntimeMXBean/TestInputArgument.sh and
test/java/lang/ref/EnqueuePollRace.java have been changed
http://cr.openjdk.java.net/~eistepan/8062536/webrev.02/
Thanks
On 07.11.2014 9:37, David Holmes wrote:
On 7/11/2014 12:36 AM, Evgeniya Stepanova wrote:
New webrev:
http://cr.openjdk.java.net/~eistepan/8062536/webrev.01/
In:
test/java/lang/management/RuntimeMXBean/TestInputArgument.sh
the use of the gc options seems incidental - it's just picking
two innocuous options to use - similar to the JpsHelper case. You
could replace +UseParallelGC with something like
+UseFastJNIAccessors (platform independent and normally true).
David
-
Thanks,
Evgeniya Stepanova
On 06.11.2014 17:35, Yekaterina Kantserova wrote:
Thanks a lot!
On 11/06/2014 02:05 PM, Evgeniya Stepanova wrote:
Hi Katja,
Ok, this seems to be a perfect solution. Thank you. I'll
change the
diff accordingly.
Thanks,
Evgeniya Stepanova
On 06.11.2014 16:56, Yekaterina Kantserova wrote:
Hi Dima,
On 11/06/2014 11:22 AM, Dmitry Fazunenko wrote:
Hi Katja,
You are right, there will be no conflict, because test
ignores any
external VM flags.
So, adding @requires seems unnecessary here, but...
Ignoring external options is bad thing, such selfish tests
are
not applicable for other areas, like GC, compiler, RT.
This particular case is to test the defined flags are shown
up as
expected.
Evgeniya,
would you mind to change JpsHelper.java instead?
+++ b/test/sun/tools/jps/JpsHelper.java
@@ -93,7 +93,7 @@
/**
* VM arguments to start test application with
*/
-public static final String[] VM_ARGS = {-Xmx512m,
-XX:+UseParallelGC};
+public static final String[] VM_ARGS = {-Xmx512m,
-XX:+PrintGCDetails};
/**
* VM flag to start test application with
*/
Best regards,
Katja
@requires will allow to modify tests to include external vm
options without any risk of bumping into conflict and extend
area
of test applicability.
But if you still believe, that @requires is not necessary -
it's
not a problem, tests could be kept as is.
Thanks,
Dima
On 06.11.2014 16:27,
RFR: 8064799: [TESTBUG] JT-Reg Serviceability tests to be run as part of JPRT submit job
Hi, Could I please get a review of this addition of SVC tests to JPRT submit jobs. So far, I'm only adding JDI tests as those are the only ones I have completed code coverage analysis on to determine the best subset to add. The other areas will be added too, but I'm adding these now to get the ball rolling asap. I've run these through JPRT once already without failures and have got two more runs in the pipe. I've also looked through the history for these tests and found that they do not have any known instabilities to worry about. Issue: https://bugs.openjdk.java.net/browse/JDK-8064799 Webrev: http://cr.openjdk.java.net/~miauno/8064799/webrev.00/ Thanks, Mikael
Re: RFR(S) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005
On 2014-11-11 01:00, Daniel D. Daugherty wrote: Greetings, I have a Solaris Full Debug Symbols (FDS) fix ready for review. Yes, it is a small fix, but it is in Makefiles so feel free to run screaming from the room... :-) On the plus side the fix does delete two work around source files (Coleen would say that's a Good Thing (TM)!) ... but you're only deleting the make files? src/os/solaris/add_gnu_debuglink/add_gnu_debuglink.c and src/os/solaris/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c could be deleted as well, right? Good idea for the fix, anyway. I opened https://bugs.openjdk.java.net/browse/JDK-8064808 to implement a similar solution in configure. /Magnus
Re: RFR: 8064799: [TESTBUG] JT-Reg Serviceability tests to be run as part of JPRT submit job
On 2014-11-13 14:56, Mikael Auno wrote: Hi, Could I please get a review of this addition of SVC tests to JPRT submit jobs. So far, I'm only adding JDI tests as those are the only ones I have completed code coverage analysis on to determine the best subset to add. The other areas will be added too, but I'm adding these now to get the ball rolling asap. I've run these through JPRT once already without failures and have got two more runs in the pipe. I've also looked through the history for these tests and found that they do not have any known instabilities to worry about. Issue: https://bugs.openjdk.java.net/browse/JDK-8064799 Webrev: http://cr.openjdk.java.net/~miauno/8064799/webrev.00/ The additional JPRT runs have completed now and have no failures. Here are also the duration (in seconds) for each test on each platform to in case anyone wonders (com/sun/jdi prefix stripped out): - | | lin_i586-c1 | lin_i586-c2 | lin_x64-c2 | osx_x64-c2 | sol_sparcv9-c2 | sol_x64-c2 | win_i586-c1 | win_i586-c2 | win_x64-c2 | - | .../AcceptTimeout| 1.24 | 1.277 | 1.308 | 1.349 | 1.54 | 1.204 | 2.184 | 2.293 | 2.34 | | .../AccessSpecifierTest | 1.689 | 1.883 | 2.021 | 2.303 | 4.892 | 2.048 | 1.332 | 1.707 | 2.19 | | .../AfterThreadDeathTest | 0.855 | 0.748 | 0.815 | 0.605 | 1.098 | 0.691 | 0.299 | 0.424 | 1.683 | | .../ArrayRangeTest | 0.659 | 0.823 | 0.794 | 0.702 | 1.445 | 0.837 | 0.783 | 0.503 | 1.267 | | .../ConstantPoolInfo | 0.589 | 0.74 | 0.791 | 0.621 | 1.067 | 0.607 | 0.315 | 0.408 | 0.674 | | .../CountFilterTest | 0.588 | 0.638 | 0.729 | 0.617 | 1.068 | 0.618 | 0.3 | 0.502 | 0.674 | | .../EarlyReturnNegativeTest | 0.724 | 0.8 | 0.824 | 0.675 | 1.186 | 0.642 | 0.362 | 0.627 | 0.736 | | .../EarlyReturnTest | 1.218 | 1.164 | 1.295 | 1.207 | 1.962 | 1.307 | 0.72 | 1.189 | 1.242 | | .../FieldWatchpoints | 0.616 | 0.628 | 0.728 | 0.6 | 1.052 | 0.683 | 0.3 | 0.408 | 0.674 | | .../FramesTest | 0.598 | 0.696 | 0.741 | 0.601 | 1.006 | 0.592 | 0.299 | 0.425 | 0.627 | | .../InstanceFilter | 0.604 | 0.677 | 0.696 | 0.587 | 1.005 | 0.608 | 0.284 | 0.393 | 0.69 | | .../InterfaceMethodsTest | 0.706 | 0.83 | 0.837 | 0.69 | 1.193 | 0.762 | 0.362 | 1.032 | 0.752 | | .../InvokeTest | 0.719 | 0.788 | 0.861 | 0.71 | 1.196 | 0.647 | 0.377 | 0.752 | 0.721 | | .../LocalVariableEqual | 0.66 | 0.662 | 0.714 | 0.622 | 1.087 | 0.715 | 0.315 | 0.383 | 0.612 | | .../LocationTest | 0.639 | 0.651 | 0.688 | 0.715 | 1.014 | 0.612 | 0.299 | 0.362 | 0.58 | | .../ModificationWatchpoints | 0.764 | 0.789 | 0.872 | 0.726 | 1.375 | 0.668 | 0.424 | 0.502 | 0.877 | | .../MonitorEventTest | 0.597 | 0.638 | 0.69 | 1.608 | 1.03 | 0.648 | 0.284 | 0.377 | 0.689 | | .../MonitorFrameInfo | 0.622 | 0.652 | 0.731 | 0.596 | 1.014 | 0.592 | 0.299 | 0.456 | 0.612 | | .../NullThreadGroupNameTest | 0.602 | 0.702 | 0.733 | 0.588 | 1.045 | 0.572 | 0.299 | 0.362 | 0.58 | | .../PopAndStepTest | 0.318 | 0.351 | 0.416 | 0.593 | 0.989 | 0.713 | 0.3 | 0.455 | 0.752 | | .../PopAsynchronousTest | 0.718 | 0.869 | 0.8 | 0.654 | 1.063 | 0.619 | 0.519 | 0.581 | 0.737 | | .../ProcessAttachTest| 6.748 | 6.482 | 6.781 |
Re: RFR: 8064799: [TESTBUG] JT-Reg Serviceability tests to be run as part of JPRT submit job
It looks good. Thanks, Serguei On 11/13/14 7:53 AM, Mikael Auno wrote: On 2014-11-13 14:56, Mikael Auno wrote: Hi, Could I please get a review of this addition of SVC tests to JPRT submit jobs. So far, I'm only adding JDI tests as those are the only ones I have completed code coverage analysis on to determine the best subset to add. The other areas will be added too, but I'm adding these now to get the ball rolling asap. I've run these through JPRT once already without failures and have got two more runs in the pipe. I've also looked through the history for these tests and found that they do not have any known instabilities to worry about. Issue: https://bugs.openjdk.java.net/browse/JDK-8064799 Webrev: http://cr.openjdk.java.net/~miauno/8064799/webrev.00/ The additional JPRT runs have completed now and have no failures. Here are also the duration (in seconds) for each test on each platform to in case anyone wonders (com/sun/jdi prefix stripped out): - | | lin_i586-c1 | lin_i586-c2 | lin_x64-c2 | osx_x64-c2 | sol_sparcv9-c2 | sol_x64-c2 | win_i586-c1 | win_i586-c2 | win_x64-c2 | - | .../AcceptTimeout| 1.24 | 1.277 | 1.308 | 1.349 | 1.54 | 1.204 | 2.184 | 2.293 | 2.34 | | .../AccessSpecifierTest | 1.689 | 1.883 | 2.021 | 2.303 | 4.892 | 2.048 | 1.332 | 1.707 | 2.19 | | .../AfterThreadDeathTest | 0.855 | 0.748 | 0.815 | 0.605 | 1.098 | 0.691 | 0.299 | 0.424 | 1.683 | | .../ArrayRangeTest | 0.659 | 0.823 | 0.794 | 0.702 | 1.445 | 0.837 | 0.783 | 0.503 | 1.267 | | .../ConstantPoolInfo | 0.589 | 0.74 | 0.791 | 0.621 | 1.067 | 0.607 | 0.315 | 0.408 | 0.674 | | .../CountFilterTest | 0.588 | 0.638 | 0.729 | 0.617 | 1.068 | 0.618 | 0.3 | 0.502 | 0.674 | | .../EarlyReturnNegativeTest | 0.724 | 0.8 | 0.824 | 0.675 | 1.186 | 0.642 | 0.362 | 0.627 | 0.736 | | .../EarlyReturnTest | 1.218 | 1.164 | 1.295 | 1.207 | 1.962 | 1.307 | 0.72 | 1.189 | 1.242 | | .../FieldWatchpoints | 0.616 | 0.628 | 0.728 | 0.6 | 1.052 | 0.683 | 0.3 | 0.408 | 0.674 | | .../FramesTest | 0.598 | 0.696 | 0.741 | 0.601 | 1.006 | 0.592 | 0.299 | 0.425 | 0.627 | | .../InstanceFilter | 0.604 | 0.677 | 0.696 | 0.587 | 1.005 | 0.608 | 0.284 | 0.393 | 0.69 | | .../InterfaceMethodsTest | 0.706 | 0.83 | 0.837 | 0.69 | 1.193 | 0.762 | 0.362 | 1.032 | 0.752 | | .../InvokeTest | 0.719 | 0.788 | 0.861 | 0.71 | 1.196 | 0.647 | 0.377 | 0.752 | 0.721 | | .../LocalVariableEqual | 0.66 | 0.662 | 0.714 | 0.622 | 1.087 | 0.715 | 0.315 | 0.383 | 0.612 | | .../LocationTest | 0.639 | 0.651 | 0.688 | 0.715 | 1.014 | 0.612 | 0.299 | 0.362 | 0.58 | | .../ModificationWatchpoints | 0.764 | 0.789 | 0.872 | 0.726 | 1.375 | 0.668 | 0.424 | 0.502 | 0.877 | | .../MonitorEventTest | 0.597 | 0.638 | 0.69 | 1.608 | 1.03 | 0.648 | 0.284 | 0.377 | 0.689 | | .../MonitorFrameInfo | 0.622 | 0.652 | 0.731 | 0.596 | 1.014 | 0.592 | 0.299 | 0.456 | 0.612 | | .../NullThreadGroupNameTest | 0.602 | 0.702 | 0.733 | 0.588 | 1.045 | 0.572 | 0.299 | 0.362 | 0.58 | | .../PopAndStepTest | 0.318 | 0.351 | 0.416 | 0.593 | 0.989 | 0.713 | 0.3 | 0.455 | 0.752 | | .../PopAsynchronousTest | 0.718 | 0.869 | 0.8 | 0.654 | 1.063 | 0.619 | 0.519 | 0.581 | 0.737 | | .../ProcessAttachTest| 6.748 | 6.482 | 6.781 | 7.115
Re: RFR(XS): JDK-8062037 java/lang/instrument/RetransformBigClass.sh should be quarantined
Thanks Dan and Serguey for the quick reply. I will change 8062037 reference to 8061177 in ProblemList.txt before pushing. Olivier. On 12/11/2014 19:22, Daniel D. Daugherty wrote: Thumbs up on the quarantine. However, I think the bug reference in ProblemList.txt should be 8061177 and not the bug used to do the quarantine. Dan On 11/12/14 11:19 AM, olivier.lagn...@oracle.com wrote: Please review this addition to ProblemList.txt Issue: https://bugs.openjdk.java.net/browse/JDK-8062037 Initial Failure: https://bugs.openjdk.java.net/browse/JDK-8061177 Webrev: http://cr.openjdk.java.net/~olagneau/8062037/webrev.00/ Retransform/RedefineBigClass.sh have been showing again random failure(s) with crash and 134 exitcode. These are stress tests and showed they need a safe and not overloaded running context to avoid random errors. They should be moved to a stress suite. Quarantining them is a first step to such move. When further moving them to some stress suite they should also be refactored (back) using memory leak detection through OOM (rather than delta measurement on free memory) , and tuned to the expected running context. Thanks, Olivier.
Re: RFR: 8064799: [TESTBUG] JT-Reg Serviceability tests to be run as part of JPRT submit job
Hi Mikael, So to be clear this adds the JDK JDI tests (select subset thereof) to -testset hotspot for full forest submissions to JPRT. Test overhead seems okay. Hopefully the test stability will be exhibited in JPRT as well as other testing. Ok. David On 14/11/2014 1:53 AM, Mikael Auno wrote: On 2014-11-13 14:56, Mikael Auno wrote: Hi, Could I please get a review of this addition of SVC tests to JPRT submit jobs. So far, I'm only adding JDI tests as those are the only ones I have completed code coverage analysis on to determine the best subset to add. The other areas will be added too, but I'm adding these now to get the ball rolling asap. I've run these through JPRT once already without failures and have got two more runs in the pipe. I've also looked through the history for these tests and found that they do not have any known instabilities to worry about. Issue: https://bugs.openjdk.java.net/browse/JDK-8064799 Webrev: http://cr.openjdk.java.net/~miauno/8064799/webrev.00/ The additional JPRT runs have completed now and have no failures. Here are also the duration (in seconds) for each test on each platform to in case anyone wonders (com/sun/jdi prefix stripped out): - | | lin_i586-c1 | lin_i586-c2 | lin_x64-c2 | osx_x64-c2 | sol_sparcv9-c2 | sol_x64-c2 | win_i586-c1 | win_i586-c2 | win_x64-c2 | - | .../AcceptTimeout| 1.24 | 1.277 | 1.308 | 1.349 | 1.54 | 1.204 | 2.184 | 2.293 | 2.34 | | .../AccessSpecifierTest | 1.689 | 1.883 | 2.021 | 2.303 | 4.892 | 2.048 | 1.332 | 1.707 | 2.19 | | .../AfterThreadDeathTest | 0.855 | 0.748 | 0.815 | 0.605 | 1.098 | 0.691 | 0.299 | 0.424 | 1.683 | | .../ArrayRangeTest | 0.659 | 0.823 | 0.794 | 0.702 | 1.445 | 0.837 | 0.783 | 0.503 | 1.267 | | .../ConstantPoolInfo | 0.589 | 0.74 | 0.791 | 0.621 | 1.067 | 0.607 | 0.315 | 0.408 | 0.674 | | .../CountFilterTest | 0.588 | 0.638 | 0.729 | 0.617 | 1.068 | 0.618 | 0.3 | 0.502 | 0.674 | | .../EarlyReturnNegativeTest | 0.724 | 0.8 | 0.824 | 0.675 | 1.186 | 0.642 | 0.362 | 0.627 | 0.736 | | .../EarlyReturnTest | 1.218 | 1.164 | 1.295 | 1.207 | 1.962 | 1.307 | 0.72 | 1.189 | 1.242 | | .../FieldWatchpoints | 0.616 | 0.628 | 0.728 | 0.6 | 1.052 | 0.683 | 0.3 | 0.408 | 0.674 | | .../FramesTest | 0.598 | 0.696 | 0.741 | 0.601 | 1.006 | 0.592 | 0.299 | 0.425 | 0.627 | | .../InstanceFilter | 0.604 | 0.677 | 0.696 | 0.587 | 1.005 | 0.608 | 0.284 | 0.393 | 0.69 | | .../InterfaceMethodsTest | 0.706 | 0.83 | 0.837 | 0.69 | 1.193 | 0.762 | 0.362 | 1.032 | 0.752 | | .../InvokeTest | 0.719 | 0.788 | 0.861 | 0.71 | 1.196 | 0.647 | 0.377 | 0.752 | 0.721 | | .../LocalVariableEqual | 0.66 | 0.662 | 0.714 | 0.622 | 1.087 | 0.715 | 0.315 | 0.383 | 0.612 | | .../LocationTest | 0.639 | 0.651 | 0.688 | 0.715 | 1.014 | 0.612 | 0.299 | 0.362 | 0.58 | | .../ModificationWatchpoints | 0.764 | 0.789 | 0.872 | 0.726 | 1.375 | 0.668 | 0.424 | 0.502 | 0.877 | | .../MonitorEventTest | 0.597 | 0.638 | 0.69 | 1.608 | 1.03 | 0.648 | 0.284 | 0.377 | 0.689 | | .../MonitorFrameInfo | 0.622 | 0.652 | 0.731 | 0.596 | 1.014 | 0.592 | 0.299 | 0.456 | 0.612 | | .../NullThreadGroupNameTest | 0.602 | 0.702 | 0.733 | 0.588 | 1.045 | 0.572 | 0.299 | 0.362 | 0.58 | | .../PopAndStepTest | 0.318 | 0.351 | 0.416 | 0.593 | 0.989 | 0.713 | 0.3 | 0.455 | 0.752 | |
