jdk 1.4.2_17 promotion failure (fragmentation?)

[Mike Finn]

Thanks for the reply. We had considered that, but, if I'm reading our 
logs correctly, it seems that CMS is started pretty close to 70 every 
time: ( here's a snippet of our CMS initial marks)

  144975.040: [GC [1 CMS-initial-mark: 10047659K(14352384K)] 
10064265K(14647296K), 0.1464111 secs]
  147242.326: [GC [1 CMS-initial-mark: 10057190K(14352384K)] 
10081419K(14647296K), 0.1732362 secs]
  149781.334: [GC [1 CMS-initial-mark: 10050150K(14352384K)] 
10063772K(14647296K), 0.1149508 secs]
  155416.122: [GC [1 CMS-initial-mark: 10048398K(14352384K)] 
10065437K(14647296K), 0.1324914 secs]
  162762.754: [GC [1 CMS-initial-mark: 10047344K(14352384K)] 
10063850K(14647296K), 0.1310949 secs]


Jones, Doug H wrote:
> Hi Mike,
>
> It is likely to be due to fragmentation of tenured (a CMS GC does not
> compact tenured). Under the 1.4.2 the 'New Generation Guarantee'
> requires that when a scavenge occurs there is contiguous space available
> in tenured equal to the size of the New area (5.0 relaxes that to just
> being enough space available, not necessarily contiguous).
>
> The fix is easy: you are half-way there with setting
> -XX:CMSInitiatingOccupancyFraction=70. However to tell the JVM to take
> notice of it you also need to add -XX:+UseCMSInitiatingOccupancyOnly,
> then CMS Collections will always kick in when tenured is approx 70%
> full. I would suspect that currently they don't until tenured is well
> above 90% full (1.4.2 is more optimistic I think than 5.0 about its
> ability to schedule a CMS GC 'JIT with a bit to spare', but
> conc-mode-failures can still be a problem under 5.0).
>
> Doug.
>  
>
> <snip>
>
>