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
