RFR: 8157153: TestStressRSetCoarsening fails with OOM

[Stefan Johansson]

Thanks Dima for taking a look!

I fixed all your comments and will include them when pushing.

Stefan

On 2016-05-30 13:59, Dmitry Fazunenko wrote:
> Hi Stefan,
>
> > Full: http://cr.openjdk.java.net/~sjohanss/8157153/hotspot.01/
>
> The fix looks good to me. Some minor comments:
>
> 310 storage.setArrayAt((to * K + k), new Object[N]); -->310 
> storage.setArrayAt(to * K + k, new Object[N]);
>
> 355 public Object[][] storage; --> 355 public final Object[][] 
> storage; 363 Object[] getForIndex(int y) {
> 364 return storage[y % usedCount];
> 365 } - no need this method.
> 368 return usedCount == storage.length; --> 368 return usedCount >= 
> storage.length;
>
> I don't need a separate review for that tiny changes.
>
> Thanks,
> Dima
>
>
> On 27.05.2016 15:48, Stefan Johansson wrote:
>>
>>
>> On 2016-05-27 13:33, Mikael Gerdin wrote:
>>> Hi Stefan,
>>>
>>> On 2016-05-26 17:20, Stefan Johansson wrote:
>>>> Hi,
>>>>
>>>> Please review this testfix for:
>>>> https://bugs.openjdk.java.net/browse/JDK-8157153
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~sjohanss/8157153/hotspot.00/
>>>
>>> Would it be possible to encapsulate the storage[] so that you don't 
>>> have to put the "% storageUsedCount" all over the place?
>>> This seems a bit fragile to me.
>> Thanks for taking a look Mikael. I agree, that my initial fix might 
>> cause problems and I like how your idea turned out:
>> Full: http://cr.openjdk.java.net/~sjohanss/8157153/hotspot.01/
>> Inc: http://cr.openjdk.java.net/~sjohanss/8157153/hotspot.00-01/
>>
>> Thanks,
>> Stefan
>>
>>>
>>> /Mikael
>>>
>>>>
>>>> Summary:
>>>> The test sometimes fail due to running out of memory and the reason is
>>>> that the test expects to be able to fit 2 objects of the size
>>>> HeapRegionSize/2 into one heap region. This assumption is ok in 
>>>> theory,
>>>> but if any object at all is allocated between the two allocations the
>>>> second one will end up in a different region. The test calculates how
>>>> many regions it should fill to get 90% of the heap used and then
>>>> allocated twice this number of objects. In many cases this will work
>>>> since nothing else is going on, but in some cases some other subsystem
>>>> might start allocating objects, and this destroys the assumptions
>>>> leading to hitting an OOME.
>>>>
>>>> The fix simply adds a second check to the allocation loop to stop as
>>>> soon as the free memory drops below 10% of the heap, this also 
>>>> requires
>>>> some extra limiting of the indexes used.
>>>>
>>>> Testing:
>>>> * Local testing as well as runs through RBT.
>>>>
>>>> Thanks,
>>>> Stefan
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20160530/f6bd07d2/attachment.htm>