It's not necessarily an evidence. Most of method handles are BMHs. So,
I'd suggest to inspect the heap dump.
In all cases when OOME happens the test operates with
BoundMethodHandle$SpeciesData class, so it indeed may be caused by
No, intermittent test failures are not acceptable. Unless there's a way
to limit produced BMHs count, the test should be excluded until
JDK-8078602 is fixed.
But is it a good idea of excluding the test? LFGarbageCollectedTest.java
fails not every time and may catch other product issues if they happen.
We can just leave it unchanged and close JDK-8068416 as a duplicate of
On 06/04/2015 12:50 PM, Vladimir Ivanov wrote:
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 ). In that case I'd prefer the test to be excluded
until BMHs are converted to VM anonymous classes.
On 6/4/15 12:10 PM, Konstantin Shefov wrote:
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.
On 06/03/2015 11:47 PM, Igor Ignatyev wrote:
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.
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.
On 03/06/2015 17:33, Konstantin Shefov wrote:
Please review the test bug fix
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.
mlvm-dev mailing list