JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector
Scott Palmer
swpalmer at gmail.com
Thu Apr 6 16:13:17 UTC 2017
> On Apr 6, 2017, at 11:06 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
>
> Hi,
>
> On Tue, 2017-04-04 at 23:48 -0700, kant kodali wrote:
>> 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?!
>
> just curious: what "smaller heap sizes" on these devices do you have
> in mind?
>
> Maybe you can even provide some kind of application where CMS
> significantly outperforms (on which metric(s)) G1?
I’ve been monitoring this conversation wondering what the alternative is for a low-pause collector.
My company makes video software and we have spent a lot of time dealing with GC pause times that can introduce glitches in a live video stream. I'm talking about network broadcast TV where glitches in the output are deal-breakers. With buffering we can reduce the disruption to a live stream, but it introduces latency. We must have low latency.
In our application, we have found that so far the CMS collector has significantly lower maximum pause times than G1. It might be possible to tune G1 to get the times down, but our initial attempts were unsuccessful. Tuning GC can be a complex and time-consuming task and there was only so much time to go down that path with G1 when we were managing with CMS. (Though we do have some ugly hacks to keep it performing, like forcing full GCs at regular intervals.)
We have max GC pause times with CMS in the range of 30-50ms. I believe we found that G1 was 2x to 3x worse than that. The Java heap size in our application is generally under 1GB. From what I’ve read it seems that G1 is really designed for larger heaps.
Regards,
Scott
More information about the jdk9-dev
mailing list