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

Lev Priima lev.priima at oracle.com
Wed Mar 18 08:12:48 UTC 2015


On 03/18/2015 04:46 AM, David Holmes wrote:
> Hi Lev,
>
> On 18/03/2015 9:07 AM, Lev Priima wrote:
>> Possible, by determining of disabled UseCompressedOops option and
>> forking vm again with required minimum heap value(-Xms).
>> Please review update: 
>> http://cr.openjdk.java.net/~lpriima/8075071/1/webrev/
>
> Yes that is the approach that is needed. But didn't you need to set 
> Xmx not Xms to deal with the MaxRAMFraction problem?
No. As I wrote before "-Xms" has priority over MaxRAMFraction: 
MaxRAMFraction can't shrink MaxHeapSize less than specified by -Xms:

java -Xms385m -XX:+PrintFlagsFinal 
-XX:MaxRAMFraction=9223372036854775807  -version | grep MaxHeapSize
     uintx MaxHeapSize                              := 
404750336                           {product}

java -Xms770m -XX:+PrintFlagsFinal 
-XX:MaxRAMFraction=9223372036854775807  -version | grep MaxHeapSize
     uintx MaxHeapSize                              := 
807403520                           {product}

>
> Thanks,
> David
>
>> Lev
>>
>> On 03/17/2015 03:23 PM, David Holmes wrote:
>>> 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
>>>>>>>>
>>>>>>
>>>>
>>




More information about the core-libs-dev mailing list