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¶meters=[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¶meters=[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