Hi Shanliang --
That's curious.
If the array is unreachable, and you do a full gc (of the stop world
variety -- either serial/parallel, or CMS/G1 with
ExplicitGCInvokesConcurrent switched off) then the array should be
reclaimed and if free space book-keeping is correct, the memory usage
after should end up strictly less than memory usage before.
Are you suggesting that GC returns without actually doing anything? Or
that the reduction in usage does not reflect in the "used" ? Both of
those would seem to be "bugs" (in the intention of HotSpot's
implementation, from what i can recall) albeit not violating the spec
of system.gc().
Confused.
-- ramki
On Sun, Aug 18, 2013 at 9:26 AM, shanliang <shanliang.ji...@oracle.com> wrote:
> I think the test was to test whether mbean.gc() did its job, so the test has
> to make sure that the MemoryUsage "after" must be LESS "before".
>
> Our experience is that System.gc does not have a guarantee, so we usually
> have to call it many times.
>
> I think it might be better to add something like the following code before
> Line 117:
>
> int = 0;
> while (usage2.getUsed() >= usage1.getUsed() && i++ < 600) {
> mbean.gc();
> Thread.sleep(200);
> }
>
> Shanliang
>
>
>
> 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
>
>
>
>
>
