RFR: 8041506 - The test gc/g1/TestHumongousShrinkHeap.java reports that memory is not de-committed
andrey.x.zakharov at oracle.com
Wed Jun 4 14:40:47 UTC 2014
Hi, Dmitry. Thanks for corrections.
Here is updated webrev:
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
> * release all allocated object except the last humongous one
> * 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.
> On 15.05.2014 15:29, Andrey Zakharov wrote:
>> 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
More information about the hotspot-gc-dev