RFR: CMM Testing: 8u40 an allocated humongous object at the end of the heap should not prevents shrinking the heap
Andrey Zakharov
andrey.x.zakharov at oracle.com
Tue Sep 2 10:13:24 UTC 2014
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.
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.
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20140902/f1726bfa/attachment.htm>
More information about the hotspot-gc-dev
mailing list