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

[Jaroslav Bachorik]

On 24.10.2013 21:33, Mandy Chung wrote:
>
> On 10/24/2013 7:01 AM, Jaroslav Bachorik wrote:
>> Hi Mandy,
>>
>> On 24.10.2013 01:02, Mandy Chung wrote:
>>>
>>> On 10/23/2013 7:32 AM, Jaroslav Bachorik wrote:
>>>> I've updated the patch. The GC is called even before the first attempt
>>>> to get the pool memory usage and System.gc() is used to perform GC (no
>>>> MXBean checks). This should simplify the change a bit.
>>>>
>>>> http://cr.openjdk.java.net/~jbachorik/8020467/webrev.02
>>>
>>> This change is okay.  It will force GC once per each memory pool that
>>> supports usage threshold (I think 3 memory pools) which is not a huge
>>> issue.  Perhaps a more reliable option is to make it an othervm test and
>>> allocating large object and calling GC once before the verification.
>>
>> Running it as othervm might improve repeatbility but I don't quite
>> follow the trick with large object. That would be effective for the
>> oldgen pools only, I suppose? There were concerns raised during the
>> review that other pools might be susceptible to the same timing
>> related problems (theoretically).
>
> This test was written before the samevm/agentvm support.  In general we
> want the tests to be reliable.   You want the System.gc() call to reduce
> the probability of the race such that the initially empty pool is being
> filled with objects between getUsage() and isUsageThresholdExceeded()
> methods are called but this has the assumption that there is some large
> object allocated and get promoted to the old gen (not done in this test
> though).  The other possibility is that the old gen is cleared although
> it might be rare in practice?  Holding on a large object will ensure
> that the old gen is always filled with something to make it more reliable.
>
>> So, if you don't feel strongy about it I would leave the rest of the
>> test as it is - that is calling System.gc() before checking the pool
>> thresholds.
>
> I just worry that this test will fail some day intermittently again.
> Since in practice the runtime has space allocated, I think running it in
> othervm would be adequate.

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

-JB-

>
> Mandy