RFR(XS): 8075071: [TEST_BUG] TimSortStackSize2.java: OOME: Java heap space: MaxHeap shrinked by MaxRAMFraction

[David Holmes]

So this is a problem that needs to be resolved. The memory requirements 
of the test are platform dependent but can't be satisfied on all 
platforms. Though I am surprised that 770M is needed given that two 
incarnations ago we set -Xmx to 385M!

But it is appearing to be impossible to run this test in a way that can 
work on all platforms.

David

On 17/03/2015 10:15 PM, Lev Priima wrote:
> Yes.
>
> Lev
>
> On 03/17/2015 02:56 PM, David Holmes wrote:
>> On 17/03/2015 9:15 PM, Lev Priima wrote:
>>> Hi David,
>>>
>>> Explicit -Xmx does not allow explicit MaxRAMFraction to shrink
>>> MaxHeapSize down to -Xms(or even less down to default InitialHeapSize in
>>> case if -Xms also wasn't set explicitly). In other words explicit -Xmx
>>> has priority over explicit MaxRAMFraction if both are set and contradict
>>> with each other.
>>
>> Okay - that's good to know.
>>
>> However the -Xmx770m is a problem - our small devices only have 512MB
>> of memory. Is the 770M only needed for 64-bit with -UseCompressedOops ?
>>
>> Thanks,
>> David
>>
>>
>>> Lev
>>>
>>> On 03/17/2015 07:40 AM, David Holmes wrote:
>>>> Hi Lev,
>>>>
>>>> On 17/03/2015 6:30 AM, Lev Priima wrote:
>>>>> Please reviewand push:
>>>>>
>>>>> Issue:https://bugs.openjdk.java.net/browse/JDK-8075071
>>>>> Patch: http://cr.openjdk.java.net/~lpriima/8075071/0/webrev/
>>>>>
>>>>> Tested locally:
>>>>> jtreg -vmoptions:"-XX:MaxRAMFraction=9223372036854775807
>>>>> -XX:-UseCompressedOops" test/java/util/Arrays/TimSortStackSize2.java
>>>>> Test results: passed: 1
>>>>
>>>> How does MaxRAMFraction interact with -Xmx?
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> Lev
>>>>>
>>>
>