I think you can simplify the logic for forcing a GC to just a simple call to "System.gc();". AFAIK System.gc() will cause a full collection to happen for all collectors.
/Staffan On 23 okt 2013, at 10:02, Jaroslav Bachorik <[email protected]> wrote: > 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- >> >
