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

[David Holmes]

On 18/03/2015 6:12 PM, Lev Priima wrote:
> 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:

No what you wrote before was that -Xmx has priority. Your original patch 
set -Xmx in addition to the existing -Xms:

!  * @run main/othervm -Xms385m -Xmx770m TimSortStackSize2 67108864

David
-----

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