Shd be ok here since presumably the test is run in its own vm where no other allocation activity is happening other than what's in the test... (Staffan/Mandy?) ysr1729 On Aug 16, 2013, at 7:39, Jon Masamitsu <jon.masamitsu@oracle.com> wrote:
Stafan,
There is a GC flag ExplicitGCInvokesConcurrent which causes a system.GC() to be done concurrently. This means that the application can be allocating during a GC so heap usage can go up. This affects both CMS and G1. Were you aware of this option and its consequences?
Ask more questions if I missed the point here.
Jon
On 8/16/2013 12:00 AM, Staffan Larsen wrote:
It maybe only happens with G1, but I don't think there is a guarantee that mbean.gc() will always cause all "freed" objects to be reclaimed. By allowing for the heap usage to be the same both before and after mbean.gc() I was hoping to make the test more stable.
But perhaps someone from the GC side can comment on what the guarantees are for mbean.gc() (which calls Runtime.gc() which calls JVM_GC() which does Universe::heap()->collect(GCCause::_java_lang_system_gc)) ?
Thanks, /Staffan
On 15 aug 2013, at 21:41, Mandy Chung <mandy.chung@oracle.com> wrote:
Hi Staffan,
Is this issue specific to G1 such as mbean.gc() doesn't collect the "freed" obj? The test wants to verify the peak usage won't change when GC frees up some space.
Mandy
On 8/15/2013 12:05 PM, Staffan Larsen wrote:
Please review this small update to the test. The fix allows for no change in heap usage to happen during a GC.
webrev: http://cr.openjdk.java.net/~sla/8023101/webrev.00/ bug: http://bugs.sun.com/view_bug.do?bug_id=8023101 (not available yet) jbs: https://jbs.oracle.com/bugs/browse/JDK-8023101
Thanks, /Staffan