RFR: 8041506 - The test gc/g1/TestHumongousShrinkHeap.java reports that memory is not de-committed

Andrey Zakharov andrey.x.zakharov at oracle.com
Wed Jun 4 14:40:47 UTC 2014

Hi, Dmitry. Thanks for corrections.
Here is updated webrev: 
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)
> - 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.

> 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