CMS Concurrent mode failure fallback to the serial old collector?
Haim Yadid
haim at performize-it.com
Fri Aug 17 14:14:08 PDT 2012
> I am analysing a GC pause problem and I have noticed that when CMS is used
> and a concurrent mode failure occurs or GC is triggered manually (by
> System.gc()) the STW collector used does not seem to be parallel. ( I am
> aware of the ExplicitGCInvokesConcurrent flag but it will not solve
> concurrent failure ).
> I tried to play with -XX:ParallelGCThreads=... -XX:ParallelCMSThreads=...
> but they seem have no effect (only on the ParNew GC).
>
> I am deducing it from the following GC log line
>
> 24.904: [Full GC (System) 24.904: [CMS: 302703K->303056K(2116864K),
> 1.0847520 secs] 484492K->303056K(2423552K), [CMS Perm :
> 7528K->7525K(21248K)], 1.0852780 secs] [Times: user=1.04 sys=0.02,
> real=1.09 secs]
> If it would have been parallel "user" would have been equal to "nThreads"
> * "real".
> In addition if I choose ParallelOld GC it will behave correctly.
>
> I really do not understand why the failover STW mechanism of CMS is not
> parallel shouldn't it be finishing the work as soon as possible ?
> I am not able to find anything useful on the internet.
>
> I think G1 behaves in the same manner BTW ( AFAIK the the fallback
> collector of G1 is copied from CMS)
>
> Help will be appreciated.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20120817/171b62b3/attachment.html
More information about the hotspot-gc-use
mailing list