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

[Ben Evans]

Hi Thomas,

If you have an example application that can demonstrably be tuned to
have a max pause time of 50ms (on, say, a 2G heap), I would suggest
that it would be highly advantageous to release it to the community as
open source, at once.

I have never seen *any* non-toy application of that heap size that can
hit that pause goal & I have looked at quite a few recently.

Thanks,

Ben


On Tue, Apr 11, 2017 at 5:29 PM, Thomas Schatzl
<thomas.schatzl at oracle.com> wrote:
> Hi Scott,
>
> On Thu, 2017-04-06 at 12:13 -0400, Scott Palmer wrote:
>> >
>> > On Apr 6, 2017, at 11:06 AM, Thomas Schatzl <thomas.schatzl at oracle.
>> > com> wrote:
>> >
>> > Hi,
>> > [...]
>>
>> 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.
>
>   the stated latency goals and heap requirements do not seem to be
> problematic to achieve with G1.
>
> The "designed for larger heaps" tends to be limited to ergonomics, i.e.
> how resources are allocated and used by default. E.g. it tends to use
> too many threads at the moment. Actually the reverse seems to be the
> case for CMS, as sometimes extensive tuning is required for larger
> heaps; this may be due to CMS having evolved with smaller applications.
> Also, since there is more experience with CMS in the community, it may
> be more approachable.
>
> But from an implementation POV, the improvements for e.g. jdk9 almost
> all improve throughput and latency regardless of heap size (some just
> don't have any impact), and we will look into improving G1 further.
>
> There are some known concerns about throughput or footprint
> requirements G1 not being able to fulfill due to more low-level
> implementation choices.
> For those known to us (e.g. [5],[6]) we earlier proposed to the
> community to work on e.g. the Throughput Barriers For G1 [1] (to get
> throughput/footprint on par with parallel/parnew) or Rebuilding
> remembered sets during Concurrent Mark [2] (to get remembered set
> footprint of "G1 proper" down); currently Stefan Johansson is working
> on a parallel full gc [3] (people are complaining that g1 full gc is
> too slow ;)) too.
> With good implementations of those in place, I am confident that in
> almost all but very extreme cases where e.g. CMS fits perfectly, G1 can
> be on par or better than both parallel and/or CMS.
>
> Actually, due to G1's peculiarities, quite a few interesting other
> optimizations that neither CMS nor Parallel are able to profit from
> easily are relatively easy to implement (like [4]).
>
> To provide an easier transition we are in the process of updating and
> heavily revising the GC tuning guide, particularly for G1. An EA
> version is available at https://docs.oracle.com/javase/9/gctuning/toc.h
> tm that gives significantly more guidance than before.
>
> If you happen to give moving to G1 another try (e.g. when transitioning
> to JDK9), and you still encounter issues, feel free to drop by with
> your problem on the hotspot-gc-use mailing list. It is always
> interesting to learn about details of particular problems people have
> with G1, and often very acceptable solutions can be found there.
>
> Thanks,
>   Thomas
>
> [1] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-November
> /019215.html
> [2] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-November
> /019217.html
> [3] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-November
> /019216.html
> [4] https://bugs.openjdk.java.net/browse/JDK-8027959 (yes, that's
> already implemented ;)
> [5] https://bugs.openjdk.java.net/browse/JDK-8062128
> [6] https://bugs.openjdk.java.net/browse/JDK-8133055