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

[Thomas Schatzl]

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