JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector

[kant kodali]

I don't really understand the rationale for JEP 291. If the whole point of
Jigsaw is to reduce the memory footprint such that Java can run effectively
on containers and smaller devices such as raspberry pi then I wonder how G1
flares on these small devices ? especially when we know CMS performs well
on smaller heap sizes. In short, I'm just trying to say while its great
that JDK team came up with Jigsaw to optimize and run effectively for
smaller devices but then we are introducing slower Garbage collector?!



On Tue, Apr 4, 2017 at 10:49 PM, Christoph Engelbert <chris at hazelcast.com>
wrote:

> Hey guys,
>
> Regarding the proposal for JEP 291 to remove the CMS GC. I understand that
> the CMS code is extremely hard to maintain and spread all over the JVM
> (tried to understand myself once and gave up ;-)) but looking at it from my
> own experience, as well as our customer base, CMS+ParNew is the most
> commonly deployed solution and a lot of applications are optimized to the
> behavior of CMS.
>
> Even with G1 coming as the default GC in Java 9 I don’t see a lot of
> people moving for existing applications (that already use explicit command
> line GC settings). Apart from the completely different behavior of G1 over
> CMS. In general I think Krik or Martijn can give a deeper insight into the
> deployment base of the different GCs.
>
> Anyhow I’m ok with a warning message as it won’t hurt application runtime
> but I think it is too early to announce removal and, as mentioned above, I
> don’t expect people to move away from it as their application system is too
> closely bound to CMS and includes weeks of work on application and GC
> optimizations.
>
> From my point of view there are other GCs that could go first but as said,
> I understand where the wish to remove CMS comes from. What would be the
> prospected timeline to remove it? Java 10?
>
> Thanks,
>
>
>
> Christoph Engelbert
> Manager Developer Relations
>
>