RFR: CMM Testing: 8u40 an allocated humongous object at the end of the heap should not prevents shrinking the heap

Jesper Wilhelmsson jesper.wilhelmsson at oracle.com
Thu Sep 4 10:45:36 UTC 2014


Looks good.
/Jesper

Andrey Zakharov skrev 3/9/14 18:22:
> Hi, all.
>
> I've reduced memory footprint for test.
> Now its passed good (577908.ute.hs_jtreg.accept.full)
>
> webrev:
> http://cr.openjdk.java.net/~jwilhelm/8041946/webrev.02/
>
> Thanks.
>
>
> On 02.09.2014 16:04, Thomas Schatzl wrote:
>> Hi,
>>
>> On Tue, 2014-09-02 at 14:13 +0400, Andrey Zakharov wrote:
>>> Hello, team.
>>>
>>> Test scenario remains old:
>>>        *  Make enough space for new objects to prevent it going old.
>>>        *  allocate bunch of small objects, and a bit of humongous
>>>          several times.
>>>        *  free almost all of allocated stuff. Check that heap shrinks
>>>          after GC.
>>> bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8041946
>>>
>>> webrev:
>>> http://cr.openjdk.java.net/~jwilhelm/8041946/webrev/
>>>
>>> Currently, I've tested this patch in aurora
>>> (574717.ute.hs_jtreg.accept.full) and its looks like, despite of
>>> reducing used memory in test
>>> it continues to fail on several boxes with OOM.
>> I looked through the Aurora run, and all failures are with 32 bit
>> system. This, and the large initial heap size (700M) suggest that this
>> is a test bug like in JDK-8056237.
>>
>> After trying the test on my local 64 bit machine, the test seems to
>> expand to 1GB at least. This seems too much for a normal 32 bit machine.
>>
>> I suggest to at least halve the memory requirements of both tests and
>> then retry.
>>
>> There does not seem to be need to actually use that much memory: the
>> behavior should be the same even on a much smaller heap.
>>
>> Thanks,
>>    Thomas
>>>
>>> Thanks.
>>>
>>>
>>> On 04.06.2014 18:40, Andrey Zakharov wrote:
>>>
>>>> Hi, Dmitry. Thanks for corrections.
>>>> Here is updated webrev:
>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8041946/webrev.00/
>>>> testing:
>>>> http://aurora.ru.oracle.com/functional/faces/ChessBoard.xhtml?reportName=J2SEFailures&parameters=[batchNames]501230.ute.hs_jtreg.accept.full
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8041946
>>>>
>>>>
>>>> On 26.05.2014 19:32, Dmitry Fazunenko wrote:
>>>>> Hi Andrey,
>>>>>
>>>>> Sorry, it took too long from me to review you change.
>>>>> I have several comments:
>>>>> - overall fix looks good
>>>>> - I think you need to change the subject: you fix 8041946, not
>>>>> 8041506
>>>>> - Replace 'TestHumongousShrinkHeap' with
>>>>> 'TestShrinkDefragmentedHeap'
>>>>> - Make MemoryUsagePrinter as static inner class of test (to avoid
>>>>> possible conflicts with other tests)
>>>>> - It would be good if you provide more text description to the
>>>>> test, like
>>>>>    * allocate small objects mixed with humongous ones
>>>>>        "ssssHssssHssssHssssHssssH"
>>>>>    * release all allocated object except the last humongous one
>>>>>        ".............................................H"
>>>>>    * invoke gc and check that  memory returned to the system
>>>>> (amount of committed memory got down)
>>>> Done
>>>>> - I'm not sure that you can predict the expected amount of
>>>>> committed memory at the end... I wouldn't use the
>>>>> expectedCommitted in the test (there are many memory consumers,
>>>>> not only your test, so the final committed should be either less
>>>>> or greater than expectedCommitted )
>>>> Well, I have tested it a lot with JFR command line options, on all
>>>> platforms. I found a lag with JMX on Solaris, and just put sleep
>>>> before measure. Also I replaced run/othervm with ProcessBuilder. I'm
>>>> planning to replace it in other early our CMM tests.
>>>>> - I think you don't need to touch  'test/TEST.groups'. There
>>>>> is :needs_g1gc tests group (hs/test/closed/TEST.group) which lists
>>>>> all g1 specific tests.
>>>>> - Please provide information on how you tested your change.
>>>> http://aurora.ru.oracle.com/functional/faces/ChessBoard.xhtml?reportName=J2SEFailures&parameters=[batchNames]501230.ute.hs_jtreg.accept.full
>>>>
>>>> Thanks
>>>>
>>>>> Thanks,
>>>>> Dima
>>>>>
>>>>>
>>>>> On 15.05.2014 15:29, Andrey Zakharov wrote:
>>>>>> Hi.
>>>>>> To proper testing of free list sorting we need to defragment
>>>>>> memory with small young and humongous objects
>>>>>> This is test scenario:
>>>>>> Make enough space for new objects to prevent it going old.
>>>>>>   - allocate bunch of small objects, and a bit of humongous
>>>>>> several times.
>>>>>>
>>>>>> Free almost all of allocated stuff. Check that heap shrinks
>>>>>> after GC.
>>>>>>
>>>>>> webrev: http://cr.openjdk.java.net/~jwilhelm/8041506/webrev.02/
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8041506
>>>>>>
>>>>>> Thanks.
>>>>>>
>>
>



More information about the hotspot-gc-dev mailing list