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-
