jmx-dev RFR 8020467: Inconsistency between usage.getUsed() and isUsageThresholdExceeded() with CMS Old Gen pool

[Staffan Larsen]

Quoting Bengt from earlier in this conversation:

"As for just doing a System.gc() to force a GC I think you can rely on that System.gc() does a full GC in Hotspot unless someone sets -XX:+DisableExplicitGC on the command line. Considering that you are relying on Hotspot specifc names for pools I don't think it is a limitation to the test to rely on the Hotspot implementatoin of System.gc()."

The spec for System.gc() doesn't promising anything, but all the collectors in Hotspot are implemented to do a full GC when System.gc() is called.

Thanks,
/Staffan

On 30 okt 2013, at 21:02, Martin Buchholz <martinrb at google.com> wrote:

> Technically, System.gc() doesn't promise anything.  I believe it may merely initiate a gc if the gc implementation is concurrent.  Check out awaitFullGc in my beloved GcFinalization
> 
> https://code.google.com/p/guava-libraries/source/browse/guava-testlib/src/com/google/common/testing/GcFinalization.java?spec=svn196edb139d49d373abbce013008da0206b83f0ca&r=ae6bc9be431d7601b1f4713679efea126673378e
> 
> 
> On Wed, Oct 30, 2013 at 9:58 AM, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> wrote:
> On 30.10.2013 17:30, Mandy Chung wrote:
> 
> On 10/30/2013 4:23 AM, Jaroslav Bachorik wrote:
> Ok. I've added a big object and an initial call to System.gc(). But
> I'm leaving the calls to System.gc() right before checking the pools
> as well - just to be sure.
> 
> http://cr.openjdk.java.net/~jbachorik/8020467/webrev.04
> 
> 
> The update looks okay and I think System.gc() at line 90 is no longer
> needed as the failure was due to the empty old gen.
> 
> thanks for the update.
> 
> Thanks for the review. I've left the System.gc() at line 90 intact - when discussing this with Bengt during the review he was concerned that other pools might be susceptible to this kind of problem and having a full GC right before the check could lessen the probability of running into the data races described in this issue.
> 
> -JB-
> 
> Mandy
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131031/13793423/attachment.html