RFR: 8157153: TestStressRSetCoarsening fails with OOM

[Dmitry Fazunenko]

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/cb7abfe4/attachment.htm>