Looks good! Thanks, /Staffan
On 31 okt 2013, at 11:27, Jaroslav Bachorik <jaroslav.bacho...@oracle.com> wrote: > On 7.10.2013 16:35, Staffan Larsen wrote: >> This will make it less likely for the test to fail, but does not guarantee >> it since there is nothing that says classloading will be done in 300 ms. Any >> failures will unfortunately be harder to reproduce. (And the test is now 300 >> ms slower to run.) >> >> A different solution is to only allow the number of classes to increase, but >> not be strict about the increase being exactly 4. That would of course make >> the test less stringent, but very stable. > > I've implemented the check for non-decrementing class count. > > I talked to SQE about not running this test with JFR but it seems that it is > not currently possible to exclude single tests from parametrized runs. > > Also, the test is marked as /othervm > > http://cr.openjdk.java.net/~jbachorik/7144200/webrev.02 > > Cheers, > > -JB- > >> >> In any case, I think the test has to be marked as /othervm since running >> other tests simultaneously will impact this test. >> >> S/taffan >> >> On 7 okt 2013, at 15:59, Jaroslav Bachorik <jaroslav.bacho...@oracle.com> >> wrote: >> >>> The test captures the number of loaded classes right at the start and then >>> checks the diffs when it's finished. However, it seems that there might by >>> some async class loading still going on, initiated by JFR. >>> >>> The patch simply adds a loop to wait for the number of loaded classes to >>> settle before continuing. This should prevent the test failing with JFR >>> intermittently. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-7144200 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/7144200/webrev.00/ >>> >>> Cheers, >>> >>> -JB- >> >
