Yes, with G1 and CMS there isn't a guarantee that this is collected if 
ExplicitGCInvokesConcurrent is enabled. 

But the test seems to be run without the option... May be it should explicitly 
turn off the option. In that case the size should definitely decrease by at 
least the size of the object reclaimed...?

--Ramki

ysr1729

On Aug 16, 2013, at 8:30, Mandy Chung <mandy.ch...@oracle.com> wrote:

> There isn't a guarantee for Runtime.gc() to reclaim any space.  On the other 
> hand, the test relies on the knowledge of our implementation (at least 
> serial, parallel, concurrent collectors) does collect the large object array 
> that is allocated in the old gen.  With G1, the behavior is probably 
> different.  Perhaps another way to fix the test is to attempt GC a few times?
> 
> Mandy
> 
> 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.ch...@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
> 

Reply via email to