RFR(XS): 8075071: [TEST_BUG] TimSortStackSize2.java: OOME: Java heap space: MaxHeap shrinked by MaxRAMFraction
David Holmes
david.holmes at oracle.com
Tue Mar 24 07:48:21 UTC 2015
Hi Lev,
On 24/03/2015 3:03 PM, Lev Priima wrote:
> Hi David,
>
> Please review and push update:
> http://cr.openjdk.java.net/~lpriima/8075071/2/webrev/ .
> NPE in WB happens when vm does not have requested flag. To make test run
> on 32bit vm, where is no UseCompressedOops flag, I've added additional
> null check in UseCompressedOops flag request:
>
> 62 Boolean compessedOops = WhiteBox.getWhiteBox()
> 63 .getBooleanVMFlag("UseCompressedOops");
> 64 final String xmsValue = "-Xms" +
> 65 ((compessedOops == null || compessedOops) ? "385" : "770")
> 66 + "m";
>
> And if it's null then we are on 32bit vm, don't have big oops and can
> run test with 385m at least.
I fixed the typo (compessedOops -> compressedOops), tested and pushed.
Thanks,
David
----
> Lev
>
> On 03/18/2015 03:25 PM, David Holmes wrote:
>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>
More information about the core-libs-dev
mailing list