On 23 okt 2013, at 10:12, Jaroslav Bachorik <jaroslav.bacho...@oracle.com> wrote:
> On 23.10.2013 10:08, Staffan Larsen wrote: >> 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. > > Hm, will it now? I had the impression that it was just hinting the GC system > to perform GC but it might decide to ignore it. I need to be sure that the GC > was performed before continuing - otherwise I might get inconsistent data > again. According to the spec it's just a hint, but I think the implementation happens to be a force. But better safe than sorry. :) /Staffan > > -JB- > >> >> /Staffan >> >> On 23 okt 2013, at 10:02, Jaroslav Bachorik <jaroslav.bacho...@oracle.com> >> 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- >>>> >>> >> >
