RFR 7144200: java/lang/management/ClassLoadingMXBean/LoadCounts.java failed with JFR enabled

[Jaroslav Bachorik]

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