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

[David Holmes]

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
>>>
>