[8u-dev] Review request : JDK-8068416: LFGarbageCollectedTest.java fails with OOME: "GC overhead limit exceeded"

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Thu Jun 4 11:19:54 UTC 2015


Konstantin,

> In all cases when OOME happens the test operates with
> BoundMethodHandle$SpeciesData class, so it indeed may be caused by
> JDK-8078602.
It's not necessarily an evidence. Most of method handles are BMHs. So, 
I'd suggest to inspect the heap dump.

> 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
> JDK-8078602.
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.

Best regards,
Vladimir Ivanov

>
> -Konstantin
>
> On 06/04/2015 12:50 PM, Vladimir Ivanov wrote:
>> 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
>>>>>
>>>
>


More information about the mlvm-dev mailing list