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

[Andrey Zakharov]

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