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
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,
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.
You are correct that the concurrent mode failure does a full GC serially.
The parallel old collector used for UseParallelGC/UseParallelOldGC was
never ported to CMS. Because of differences between UseParallelGC and
CMS, it is more work than we had expected.
I think G1 behaves in the same manner BTW ( AFAIK the the fallback
collector of G1 is copied from CMS)
Yes, G1 behaves the same. G1 will not use the UseParallelGC implementation
for a parallel full collection but will implement one in line with G1's
Currently the G1 guys have been focusing on better policies for achieving
pause goals and avoiding full collections. Last I heard there was at
work to be done for class unloading (JEP 156) before the parallel full