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

[Andrey Zakharov]

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&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.
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20140902/f1726bfa/attachment.htm>