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 <marti...@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.bacho...@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
> 
> 

Reply via email to