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 11:46:17 UTC 2015
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.
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 .
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.
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