RFR: Update to test java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java

[Staffan Larsen]

Thanks Bengt.

I'll make those changes before pushing the fix.

/Staffan

On 7 maj 2013, at 13:24, Bengt Rutisson <bengt.rutisson at 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
>