JEP 248: Make G1 the Default Garbage Collector (original) (raw)
Staffan Friberg staffan.friberg at oracle.com
Thu Jun 25 17:10:51 UTC 2015
- Previous message: JEP 248: Make G1 the Default Garbage Collector
- Next message: JEP 248: Make G1 the Default Garbage Collector
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: JEP 248: Make G1 the Default Garbage Collector
- Next message: JEP 248: Make G1 the Default Garbage Collector
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]