[8u-dev] Review request : JDK-8068416: LFGarbageCollectedTest.java fails with OOME: "GC overhead limit exceeded"
Konstantin Shefov
konstantin.shefov at oracle.com
Thu Jun 4 11:28:09 UTC 2015
Vladimir
On 06/04/2015 02:19 PM, Vladimir Ivanov wrote:
> 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.
I will inspect the heap dump. If it is really JDK-8078602, I will
exclude the test.
-Konstantin
>
>> 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 core-libs-dev
mailing list