RFR (XXS): 8164133: Tests gc/arguments/TestAlignmentToUseLargePages.java and gc/cms/TestBubbleUpRef.java use too small heap

Jon Masamitsu jon.masamitsu at oracle.com
Tue Aug 23 05:27:50 UTC 2016


Sangheon,

Thanks for the explanation.  I was using a different class
machine that did not have the same large page size.

Jon

On 8/22/2016 4:30 PM, sangheon wrote:
> Hi Jon,
>
> On 08/22/2016 02:55 PM, Jon Masamitsu wrote:
>>
>>
>> On 08/22/2016 12:49 PM, sangheon wrote:
>>> Hi Dima and Jon,
>>>
>>> Let me interrupt a little bit.
>>>
>>> As you know, we can have quite big heap alignment with large pages 
>>> enabled. And this affects to our heap ergonomics.
>>> However, as the test case tests only whether the VM is successfully 
>>> initialized or not, I think large 'Xms' option is enough to fix the 
>>> problem.
>>> For me, the new 'Xms/Xmx' values seem always OK to initialize VM.
>>>
>>> Jon, the original test failure contains '-Xms7m -Xmx9m' options.
>>> "GC triggered before VM initialization completed. Try increasing 
>>> NewSize, current value 1280K. "
>>
>> If I execute "java -XX:+PrintGCDetails -XX:+UseConcMarkSweepGC -Xms7m 
>> -Xmx9m -XX:+UseLargePages -version"
>>
>> I see
>>
>> [0.165s][info   ][gc,heap,exit ] Heap
>> [0.165s][info   ][gc,heap,exit ]  par new generation   total 2432K, 
>> used 1679K [0x00000000ff600000, 0x00000000ff8a0000, 0x00000000ff8a0000)
>> [0.165s][info   ][gc,heap,exit ]   eden space 2176K,  77% used 
>> [0x00000000ff600000, 0x00000000ff7a3d30, 0x00000000ff820000)
>> [0.165s][info   ][gc,heap,exit ]   from space 256K,   0% used 
>> [0x00000000ff820000, 0x00000000ff820000, 0x00000000ff860000)
>> [0.165s][info   ][gc,heap,exit ]   to   space 256K,   0% used 
>> [0x00000000ff860000, 0x00000000ff860000, 0x00000000ff8a0000)
>> [0.165s][info   ][gc,heap,exit ]  concurrent mark-sweep generation 
>> total 5504K, used 0K [0x00000000ff8a0000, 0x00000000ffe00000, 
>> 0x0000000100000000)
>>
>> which says "par new generation   total 2432K" so isn't 2432K the 
>> ParNew size?
> In your log, you are right.
> But I want to ask you whether you ran the above command on the same or 
> similar host machine?
>
> I got below message from same kind of machine.
>
> $ java -Xlog:gc+heap=trace -Xms7M -Xmx9M -XX:+UseConcMarkSweepGC 
> -XX:+UseLargePages -version
>
> [0.004s][trace][gc,heap] CMS ergo set MaxNewSize: 0
> [0.004s][trace][gc,heap] CMS set min_heap_size: 7340032 
> initial_heap_size:  7340032 max_heap: 0
> [0.020s][debug][gc,heap] Minimum heap 536870912  Initial heap 
> 536870912  Maximum heap 536870912
> [0.020s][trace][gc,heap] 1: Minimum young 1310720 _*Initial young 
> 1310720*_  Maximum young 1310720
> [0.020s][trace][gc,heap] Minimum old 65536  Initial old 535560192 
> Maximum old 535560192
> Java HotSpot(TM) 64-Bit Server VM warning: Failed to reserve shared 
> memory. (error = 1)
> [0.766s][debug][gc,heap] GC(0) Heap before GC invocations=0 (full 0):
> [0.766s][debug][gc,heap] GC(0) *_par new generation   total 1152K_*, 
> used 1024K [0x00000000e0000000, 0x00000000e0140000, 0x00000000e0140000)
> [0.766s][debug][gc,heap] GC(0)   eden space 1024K, 100% used 
> [0x00000000e0000000, 0x00000000e0100000, 0x00000000e0100000)
> [0.766s][debug][gc,heap] GC(0)   from space 128K,   0% used 
> [0x00000000e0100000, 0x00000000e0100000, 0x00000000e0120000)
> [0.766s][debug][gc,heap] GC(0)   to   space 128K,   0% used 
> [0x00000000e0120000, 0x00000000e0120000, 0x00000000e0140000)
> [0.767s][debug][gc,heap] GC(0)  concurrent mark-sweep generation total 
> 523008K, used 0K [0x00000000e0140000, 0x0000000100000000, 
> 0x0000000100000000)
> [0.767s][debug][gc,heap] GC(0)  Metaspace       used 3786K, capacity 
> 4480K, committed 4480K, reserved 1056768K
> [0.767s][debug][gc,heap] GC(0)   class space    used 338K, capacity 
> 384K, committed 384K, reserved 1048576K
> [0.798s][info ][gc,heap] GC(0) ParNew: 1024K->126K(1152K)
> [0.799s][info ][gc,heap] GC(0) CMS: 0K->738K(523008K)
> [0.799s][debug][gc,heap] GC(0) Heap after GC invocations=1 (full 0):
> [0.799s][debug][gc,heap] GC(0)  par new generation   total 1152K, used 
> 126K [0x00000000e0000000, 0x00000000e0140000, 0x00000000e0140000)
> [0.799s][debug][gc,heap] GC(0)   eden space 1024K,   0% used 
> [0x00000000e0000000, 0x00000000e0000000, 0x00000000e0100000)
> [0.799s][debug][gc,heap] GC(0)   from space 128K,  98% used 
> [0x00000000e0120000, 0x00000000e013f9c8, 0x00000000e0140000)
> [0.799s][debug][gc,heap] GC(0)   to   space 128K,   0% used 
> [0x00000000e0100000, 0x00000000e0100000, 0x00000000e0120000)
> [0.799s][debug][gc,heap] GC(0)  concurrent mark-sweep generation total 
> 523008K, used 738K [0x00000000e0140000, 0x0000000100000000, 
> 0x0000000100000000)
>
> So the ParNew size is 1152K and the initial young size is 
> 1280K(1310720) from my log.
>
> FYI, the test machine has 524288 kB of huge page size and I think 
> yours has different huge page size.
>
> Thanks,
> Sangheon
>
>
>>
>> Jon
>>
>>>
>>> To answer to Jon's original question, the reason of "1280k 
>>> (1310720)" is that NewSize(default value of 1363144) is aligned to 
>>> gen alignment(65536) from GenCollectorPolicy::initialize_flags(). 
>>> collectorPolicy.cpp:line 316
>>> We resize NewSize from GenCollectorPolicy::initialize_size_info() if 
>>> needed, but it seems like this is not the case.
>>>
>>> Given above, the patch seems okay.
>>>
>>> Thanks,
>>> Sangheon
>>>
>>>
>>> On 08/22/2016 10:37 AM, Jon Masamitsu wrote:
>>>>
>>>>
>>>> On 08/22/2016 08:55 AM, Dmitry Fazunenko wrote:
>>>>> Jon,
>>>>>
>>>>> The problem could be reproduced by the following command:
>>>>>
>>>>> #> java -Xmx3m -XX:+UseConcMarkSweepGC -XX:+AggressiveOpts -version
>>>>> Error occurred during initialization of VM
>>>>> GC triggered before VM initialization completed. Try increasing 
>>>>> NewSize, current value 640K.
>>>>
>>>> I didn't notice that "-Xmx3m" was on the command line for the 
>>>> original failure.
>>>> Without -Xmx3m I expected that the default heap was large and 
>>>> wondered why
>>>> NewSize was so small.
>>>>
>>>> Jon
>>>>
>>>>>
>>>>> increasing Xmx from 3m to 4m helps:
>>>>>
>>>>> #> java -Xmx4m -XX:+UseConcMarkSweepGC -XX:+AggressiveOpts -version
>>>>> java version "9-ea"
>>>>> Java(TM) SE Runtime Environment (build 9-ea+132)
>>>>> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+132, mixed mode)
>>>>>
>>>>> I don't see anything suspicious in the GC log (attached).
>>>>>
>>>>> There is no requirement to minimal heap required for Hotspot to 
>>>>> work normally, so I think the tests should not start VM with so 
>>>>> small heaps.
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Dima
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 19.08.2016 21:02, Jon Masamitsu wrote:
>>>>>> Dima,
>>>>>>
>>>>>> The error message I see in the logs is
>>>>>>
>>>>>> GC triggered before VM initialization completed. Try increasing 
>>>>>> NewSize, current value 1280K.
>>>>>>
>>>>>> Do you know why the NewSize is so small?  I ask because I'm
>>>>>> not sure setting a larger heap size will always fix this failure.
>>>>>>
>>>>>> If the test is run (with the parameters that fail) and 
>>>>>> -Xlog:gc*=trace, you might
>>>>>> see why the NewSize is so small (if you don't know now).
>>>>>>
>>>>>> Jon
>>>>>>
>>>>>>
>>>>>> On 8/19/2016 9:02 AM, Dmitry Fazunenko wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> May I have to get a couple of reviews for a trivial fix:
>>>>>>>
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8164133
>>>>>>> http://cr.openjdk.java.net/~dfazunen/8164133/webrev.01/
>>>>>>>
>>>>>>> Two tests set very small maximum heap size, which may cause:
>>>>>>>   starts VM with too small heap size, which might cause
>>>>>>>   Error occurred during initialization of VM
>>>>>>> None of those tests does really require such a small heap, so 
>>>>>>> just increasing should help.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Dima
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20160822/f9b34f06/attachment.htm>


More information about the hotspot-gc-dev mailing list