On 22.10.2013 22:04, Mandy Chung wrote:
Hi Jaroslav,
On 10/22/13 6:47 AM, Jaroslav Bachorik wrote:
Please, review the following test fix:
Issue: https://bugs.openjdk.java.net/browse/JDK-8020467
Webrev: http://cr.openjdk.java.net/~jbachorik/8020467/webrev.01
Have you considered to force GC when getUsed() == 0 regardless of which
memory pool it is? This will avoid special casing for CMS old gen in
the test and will handle similar issue in the future for a different
collector implementation. To make the test reliable, the test should
still pass if the memory pool has no object in it (G1 survivor space
case?).
Hi Mandy,
I don't know whether GC will help for other pools - but I can enable it
for all pools - it should not hurt.
The test should pass even with on object in the monitored pool since the
pool should not report an exceeded threshold.
-JB-
Mandy
The test tries to make sure that the "pool usage threshold" trigger
and the reported pool memory usage are not contradicting each other.
The problem is that it is not possible to get the "pool usage
threshold exceeded" flag and the pool memory usage atomicly in regard
to the GC. Specifically, when "CMS Old Gen" pool is examined and the
usage is retrieved before a GC promotes some objects to the old gen
but the usage threshold is checked after the GC has promoted some
instance into the old gen the test will fail.
The patch makes sure that there are some instances promoted in "CMS
Old Gen" before checking the "pool usage threshold" to get
semi-consistent view.
Thanks,
-JB-
