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. 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-
