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

[David Holmes]

On 18/03/2015 9:46 PM, Lev Priima wrote:
> On 03/18/2015 01:52 PM, David Holmes wrote:
>> 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
> Yes this fix will also work. Both -Xms -Xmx have priority over
> MaxRAMFraction. MaxRAMFraction can't shrink MaxHeapSize less than either
> -Xms or -Xmx.

Let me see if I have this straight. With -Xms385M ergonomics will select 
a maximum heap size, and that size is adequate to run the test without 
additional flags. However if MaxRAMFraction is specified then that 
maximum heap size gets reduced and the test then fails on 64-bit when 
compressed oops are disabled. The original version of the fix set 
-Xmx770M in addition to -Xms385M and that stops the affect of 
MaxRAMFraction, and so the test passes (but seemingly using G1 can 
change that?). Alternatively we can just set -Xms770M, but that won't 
work for systems with less memory, so the current fix simply selects the 
-Xms value based on whether or not we're using compressed oops, and 
launches a new VM using that value.

Okay got it.

> Explicit value of -Xmx770m with program which actually required and
> allocate less memory(385m) is not a problem on machine with 512m until
> we don't switch -XX:+UseG1GC.
> That's why I had have agreed with declining this fix .

I originally said the -Xmx770 would be a problem for a machine with 
512MB, but as you note it won't be a problem unless > 512MB is actually 
needed - in which case there is nothing we can do. So my objection was 
unfounded - sorry for the confusion on that.

> New fix will work with either -Xms or -Xms in this line:
> !             final String xmsValue = "-Xms" + (WhiteBox.getWhiteBox()
>
> -Xms makes tests more robust if jdk footprint will increase a little.
> -Xmx will be better if we also want to catch possible jdk footprint
> regression by this test.

Okay. As long as it works on all platforms with all options. :)

Thanks,
David

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