On 7.10.2013 16:22, Daniel Fuchs wrote:
Hi Jaroslav,
I am not an expert in classloading but I don't see any obvious
issue with what you propose.
I hope there is none :) If the number of loaded classes is not changing
the test should continue immediately. The only problem could be loading
the classes veeery slowly - not increasing the number of the loaded
classes in 300ms interval. We could get a false positive and end up with
the same failure as now :(
I wonder whether making the test always run in /othervm mode
might make it more stable.
I don't know. I was not able to reproduce the problem but from the
description it sounds like it is spotted only with JFR enabled. So, I
suppose, running it in othervm would not help at all.
-JB-
best regards,
-- daniel
On 10/7/13 3:59 PM, Jaroslav Bachorik 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-
