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

[Martin Buchholz]

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<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/20131030/adb1cf70/attachment.html