RFR (S): 8023101 java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails
Srinivas Ramakrishna
ysr1729 at gmail.com
Fri Aug 16 19:26:50 UTC 2013
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 at 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 at 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
>
More information about the hotspot-gc-dev
mailing list