Konstantin,
Have you looked into the heap dump to understand why the test provokes
an OOM? Limiting test iterations is counter-productive, because it
defeats the purpose of the test.
Probably, the failure is caused by BMHs which aren't collected (see
JDK-8078602 [1]). In that case I'd prefer the test to be excluded until
BMHs are converted to VM anonymous classes.
Best regards,
Vladimir Ivanov
[1] https://bugs.openjdk.java.net/browse/JDK-8078602
On 6/4/15 12:10 PM, Konstantin Shefov wrote:
Igor,
It seems I have given you wrong information. This test fails with OOME
against JDK 9 also, I managed to reproduce the failure now.
It was hard to reproduce it because of randomness, I need to rerun the
test 50 times. Although the test seems to fail with OOME more often
against JDK 8u, but I think it is just factor of randomness in the test.
So I do not think it is a product bug then.
-Konstantin
On 06/03/2015 11:47 PM, Igor Ignatyev wrote:
Konstantin,
do you have an explanation why the test passes on jdk 9?
from my point of view, it indicates there is a product bug in 8u which
should be fixed and your fix just hides it.
Igor
On 06/03/2015 10:14 PM, Seán Coffey wrote:
I bumped into this failure myself today. I think you've got a typo.
440 should be 40. Looks like a good approach otherwise.
Regards,
Sean.
On 03/06/2015 17:33, Konstantin Shefov wrote:
Hello,
Please review the test bug fix
https://bugs.openjdk.java.net/browse/JDK-8068416
Webrev is http://cr.openjdk.java.net/~kshefov/8068416/webrev.00/
Test fails only against JDK 8u and passes against JDK 9.
Fix is to reduce the number of iterations to 40. With that number of
iterations the test passes on those hosts where it failed before.
The number of iterations the test start to fail is 65.
Before the fix the number of iterations was 84.
Thanks
-Konstantin
