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 > >
