Thanks Bengt. I'll make those changes before pushing the fix.
/Staffan On 7 maj 2013, at 13:24, Bengt Rutisson <bengt.rutis...@oracle.com> wrote: > > Hi Staffan, > > I think this looks good. > > Two minor comments about the @run commands. > > Both of these will use the SerialOld collector and since the test really only > test the old generation I think one is enough: > > * @run main/othervm -XX:+UseSerialGC -Xmn8m ResetPeakMemoryUsage > * @run main/othervm -XX:+UseParNewGC -Xmn8m ResetPeakMemoryUsage > > I would suggest to keep the SerialGC version. > > Also, I think the G1 @run command should work with the same settings as the > other GCs. To be on the safe side it might be worth setting the region size > to make sure it matches the young gen size. So: > > * @run main/othervm -XX:+UseG1GC -Xmn8m -XX:G1HeapRegionSize=1m > ResetPeakMemoryUsage > > Thanks, > Bengt > > > On 5/6/13 5:17 PM, Staffan Larsen wrote: >> This test had a number of problems reported against it: >> >> http://bugs.sun.com/view_bug.do?bug_id=7148492 >> http://bugs.sun.com/view_bug.do?bug_id=6980985 >> http://bugs.sun.com/view_bug.do?bug_id=7181907 >> >> This overhaul of the test tries to address all of these and improve the test >> robustness. The changes I have done are: >> >> - Make sure the allocated large object is not easy to optimize away by >> storing it in a public field. >> - Removed the dynamic calculation of the large object's size since this >> sometimes caused problems. >> - Added GC configuration parameters to make sure the large object is >> allocated in the old gen. >> - Added GC configuration parameters to run the test with all GC algorithms. >> - Changed the printMemoryUsage() method to take MemoryUsages as parameters >> so it prints the same values as were used for comparisons. >> - Changed some incorrect '>' to '<' in printouts. >> - Removed the assumption that peak usage after the GC should be the same as >> before the GC. This is not true since "stuff" may have been moved from >> younger generations into the old gen thereby increasing the heap. >> >> webrev: http://cr.openjdk.java.net/~sla/7148492/webrev.00/ >> >> I've been running the test through JPRT a couple of times to try to ensure >> that it always passes. >> >> Thanks, >> /Staffan >
