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

[Konstantin Shefov]

Vladimir

I looked at heap dump using jhat tool.
Heap contained 2452 occurences of 
java.lang.invoke.BoundMethodHandle$Species_* classes by the moment OOME 
happened.
So looks like java.lang.invoke.BoundMethodHandle$Species_* classesare 
not unloading as it is said in JDK-8078602 [1].
So I will exclude the test with "@ignore 8078602" tag.

[1] https://bugs.openjdk.java.net/browse/JDK-8078602

-Konstantin

On 06/04/2015 02:28 PM, Konstantin Shefov wrote:
> 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
>>>>>>>
>>>>>
>>>
>