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

Lev Priima lev.priima at oracle.com
Tue Mar 17 12:15:18 UTC 2015


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




More information about the core-libs-dev mailing list