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

[Thomas Schatzl]

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