JEP 248: Make G1 the Default Garbage Collector

[Staffan Friberg]

Hi,

As JEP 248 moved to target, we would like to expand on the testing we 
have done.  We want to ask the community to help us make sure we get the 
best data points.  These data points will be used to evaluate if there 
are critical issues for G1 that can not be addressed in JDK 9 time frame.

Switching to G1 as the default GC in JDK 9 will in the end come down to 
a judgment call with the data collected at the decision time.

We would like to get your feedback on all experiences, good, neutral and 
bad. Usually bad experiences is what generates blogs and emails, the 
other data points are not always easy to get.
*
**Metrics*
The following we see as the key metrics to gather data around to 
determine the impact of the switch. Not all metrics will be interesting 
for every application, but a default collector needs to behave well in 
them as a whole.

  * *Startup Time *- VM Initialization
      o G1 is a more complex GC than Parallel GC and requires a bit more
        infrastructure to be configured to enable concurrent marking and
        mixed collections.
      o This is most critical for short lived applications (such as
        simple command line tools or build tools), where the execution
        time is largely impacted by the time it takes to initialize the VM.
      o *Goal:* The VM initialization time must not have a major impact
        the run time of short running applications

  * *Throughput* - Code Performance
      o The pure application performance should not be too adversely
        affected by which GC is used.
      o Due to the heavier write barriers used in G1 there may be a
        performance impact. But the impact varies for  different
        applications.
      o *Goal:* The performance is good enough so the general
        recommendation does not end up being to set the Parallel GC as
        part of application launch scripts.

  * *Footprint *- Total Memory Usage
      o G1 is a more complex GC than Parallel GC and requires a bit more
        infrastructure to be configured to enable concurrent marking and
        mixed collections.
      o This also ties into the Ergonomics metric below in that the
        Ergonomics need to keep the memory usage balanced by not
        expanding the heap too aggressively.
      o *Goal*: The total memory usage of the Java process must be kept
        reasonable.

  * *Ergonomics *- GC Behavior and Pauses
      o A default GC need to be able to handle a reasonably large set of
        different types of applications Out-Of-The-Box without extensive
        tuning.
          + A user should be able to just run their Java application,
            potentially just setting the heap size and pause time goal,
            and have it behave well.
          + The GC needs to be able size the heap and its sub components
            using dynamic ergonomics.
      o The default GC needs to be able to avoid long costly Full
        collections by using Ergonomics to self tune depending on the
        workload.
      o *Goal*: The GC Ergonomics must be able to handle common
        applications without causing performance overhead or Full GCs

*Applications*
We are focusing on general Java applications, and not on applications 
that are very dependent on extreme GC tuning. Applications not 
considered a target for this switch includes applications requiring low 
latency with milliseconds, micro or no-pause requirements, nor very 
large heap applications that use multiple of 10s or 100s of GB of heap. 
The focus is on applications that are normally not tuned, either because 
there has never been a need to do so or they are used by people not 
accustomed to GC tuning.

  * *Unaffected Applications*
      o Client VM Application:  The Client VM will continue to use the
        Serial Collector, and applications such as Applets and regular
        Java applications using the 32bit JRE on Windows with only the
        client VM would not be affected.

      o "Tuned Applications":  Any application that specifically sets
        the GC will not be impacted by this change.

  * *Affected Applications*
      o Command Line Tools
          + Command line tools are often batch type jobs and are often
            fairly short running, so the GC pauses are of less concern
            as long as the execution is finished as soon as possible.
            Example tools are the Java Compiler, Scala Compiler, Maven
            and Gradle. The key metrics are Startup Time and Ergonomics
            to make sure the tool starts fast and that the GC can
            quickly adapt to the behavior of the application. For semi
            long running compilations the Throughput will become a
            factor as well.
      o UI Applications
          + UI applications often don't set a specific GC, they might
            tune the heap size depending on the requirements of the
            application. End users of UI:s most likely don't know how to
            tune the VM, or the fact that the application is written in
            Java. As an example NetBeans by default only increases the
            minimum heap size as the only GC related tuning and let the
            ergonomics handle the rest. As a data point here, Java
            Mission Control is configured to run with G1 without issues
            so far. For most desktop UI application pure throughput is
            less critical. What tends to most noticeable is stalls due
            to GC pauses, so Ergonomics is probably the most important
            metric, together with Footprint as you do not want you
            application to use up all the memory on you desktop/laptop.
      o Applications using the Default GC
          + This is the area where we need the most help. We have
            internal workloads and benchmarks we can run, but that set
            will always be infinitely small compared to what is used
            across the Java community. This is also the reason why we
            enable this early to expand the amount of testing and
            feedback we are able to get. For these applications all the
            metrics apply, but their importance will vary from workload
            to workload.

    We would like to encourage and collaborate on further community
    polls and surveys on this matter, to gain more valuable insights on
    questions such as:

      * Do you specify GC on the command line?
      * Are you tuning GC, but do not specify UseParallelGC since it was
        the default anyway?
      * Do you specify the minimum and/or maximum heap size and nursery size
      * Is this a distributed end-user application or a server application?

Regards,
Staffan and Jenny
Java SE Performance

On 06/05/2015 10:11 AM, Ben Evans wrote:
> Hi,
>
> I like the plan, but this statement is really quite bullish,
> especially (IMO) on the available evidence.
>
> G1 was always marketed as the replacement for CMS. In field experience
> so far, that hasn't happened, and I feel that we are glossing over the
> fact that we are now thinking of G1 as a replacement for Parallel.
>
> Certainly none of the testing I've done has been about Parallel -> G1
> - it's all been CMS vs G1. I will be happy to start working with
> clients to try to cover the Parallel vs G1 space, but that hasn't
> happened up until now.
>
> Neither do I think we should be under any illusions that a very large
> number of installs are going to be affected.
>
> It may not be all that representative, but here are the results of a
> quick community straw poll I ran over the last couple of days:
>
> A single question: "Which Garbage Collector Does Your Application Use?
> " yielded these results:
>
> Concurrent Mark & Sweep (CMS)
> 23.94%
> 85
> –
> Garbage First (G1GC)
> 10.70%
> 38
> –
> Parallel (because I explicitly set it)
> 5.07%
> 18
> –
> Default (this actually gives you Parallel)
> 39.15%
> 139
> –
> I Don't Know
> 21.13%
> 75
>
> Total: 355
>
> The clear, stand-out winner is Default, with ~40% of installs using
> this, and therefore being exposed to the proposed change. That makes
> me very nervous.
>
> So, whilst I'm not saying we shouldn't do this, and I know that
> community members, including Kirk, myself & the other jClarity folks
> will help to get some better data, I'd argue that we're still a long
> way from being certain that we're ready for this change.
>
> Thanks,
>
> Ben
>
>
> On Fri, Jun 5, 2015 at 1:12 PM, Stefan Johansson
> <stefan.johansson at oracle.com> wrote:
>> On 2015-06-05 00:08, mark.reinhold at oracle.com wrote:
>>> 2015/6/4 6:44 -0700, charlie.hunt at oracle.com:
>>>> Wanted to come back to this thread, continue the dialog, reiterate the
>>>> objective, (try to) summarize the concerns and put forth a potential
>>>> plan for this JEP going forward.
>>>>
>>>> Intent: Use G1 GC as the default collector chosen by the JVM when no
>>>> GC is explicitly set at the JVM command line.
>>>>
>>>> ...
>>> Charlie -- thanks for the excellent summary of this wide-ranging
>>> discussion!
>>>
>>>> ...
>>>>
>>>> Suggested plan for moving forward:
>>>> - Make G1 the default collector in JDK 9, continue to evaluate G1 and
>>>>     enhance G1 in JDK 9
>>>> - Mitigate risk by reverting back to Parallel GC before JDK 9 goes
>>>>     “Generally Available” (Sept 22, 2016 [1]) if warranted by continuing
>>>>     to monitor observations and experiences with G1 in both JDK 9
>>>>     pre-releases and latest JDK 8 update releases
>>>> - Address enhancing ergonomics for selecting a default GC as a
>>>>     separate JEP if future observations suggests its needed
>>> I think this is a fine plan.
>>>
>>> Stefan -- To move forward with JEP 248, could you please revise the
>>> second item in the "Risks and Assumptions" section to note that there
>>> is some concern that G1 might not be ready to become the default, that
>>> making it the default now will allow us to get more feedback on it, and
>>> that if it proves to be not ready then we'll revert the default to the
>>> Parallel GC in time for JDK 9 GA?
>> Mark, I've extended second item as follows:
>>    - G1 is seen as a robust and well-tested collector. It is not expected
>>      to have stability problems, but becoming the default collector will
>>      increase its visibility and may reveal previously-unknown issues. If
>>      a critical issue is found that can't be addressed in the JDK 9 time
>>      frame, we will revert back to use Parallel GC as the default for the
>>      JDK 9 GA.
>>
>> Thanks,
>> Stefan
>>
>>
>>> Ben -- Can you live with this plan?
>>>
>>> - Mark
>>
>
>