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

[Mandy Chung]

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.

Mandy