JEP 248: Make G1 the Default Garbage Collector

[John Rose]

Thanks Charlie; this is a good summary of the change of (the
default setting of) the GC and the effect on JDK 9 users.

If you know you are sensitive to GC performance, and you explicitly
select a GC algorithm on the command line, this default change won't
affect you.  If you don't worry about GC performance, we don't expect
that this default change will affect you noticeably, but if it does we want
to know about it.

Also, at the risk of stating the obvious:  This change is to the bleeding edge
of Java's next release, not the current release (JDK 8).  The change will
affect people who have chosen to work with early, pre-release versions of
JDK 9.  And those are exactly the people we need to help us with this next
step.

— John

P.S. More background, from my POV:

G1 is both a set of newer GC algorithms and a framework for regionalized
management of the heap.  We have invested heavily (>10y) in this framework
because we believe it will give us the means to scale best to current and
future memory systems, while flexibly balancing pause time and throughput.

The point of regionalization is that the GC can divide and conquer its reference
tracing work by summarizing "remembered sets" for each region, and can
then concentrate memory reclamation work in regions in which the most
garbage is being created, treating "quiet" regions with little effort.  There
is no single "old generation" to accumulate fragmentation or scaling problems.
Regionalization should also help us, in the future, with more exotic use
cases, such as mapping object graphs directly from disk.

Our internal testing leads us to believe that our current specific algorithms
are now well-tuned enough to replace the previous default, for typical users.
Thus we wish to switch the default for development builds of JDK 9,
so that we can, as a wider community, verify this belief, debug it,
or retract it.


On Jun 4, 2015, at 6:44 AM, charlie hunt <charlie.hunt at oracle.com> wrote:
> 
> 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.
> 
> Points to consider:
> - No new feature capabilities are being added or removed. Anyone who wants to use a particular GC can use his or her favorite GC.
> - Potential impact, (positive or negative), is limited to those Java apps that do not specify a GC at the JVM command line.
>  . No impact to any app using CMS GC
>  . No impact to any app explicitly specifying Parallel GC
>  . No impact to any app using Serial GC 
>  . No impact to any app using G1 GC
> - G1 by design offers an improved mix, or balance of GC performance (throughput, latency and footprint) over Parallel GC which was designed to be a throughput collector.
> - G1 ongoing enhancements will continue in JDK 9 through Dec 10, 2015, with bug fixes through April 21, 2016 [1].
> - There are, and will be G1 enhancements in JDK 9, that are not, and may not be back ported to a JDK 8 update release.
>  . It is possible should a G1 issue surface in JDK 8, it may be addressed via an enhancement in JDK 9.
> 
> Concerns mentioned:
> - Is G1 mature enough to make the default collector?
>  * Observations and experiences, (both positive and negative) ranging from pre-production support of G1 (pre JDK 7u4) through JDK 8u45.
>  ** Mention of potential G1 corrupting indexes in Lucene, bug report [2]. Dawid Weiss, a committer to Lucene, mentioned the issue is very hard to reproduce and pinpoint. More info on this below. [2]
> - Should ergonomics be enhanced to better support the selection of a default GC?
> 
> 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
> 
> Comments?
> 
> thanks,
> 
> charlie
> 
> [1]: http://openjdk.java.net/projects/jdk9/ <http://openjdk.java.net/projects/jdk9/>
> [2]: https://bugs.openjdk.java.net/browse/JDK-8038348 <https://bugs.openjdk.java.net/browse/JDK-8038348>
> Dawid Weiss and Vladimir Kozlov (HotSpot JIT compiler committer) have tried multiple times to reproduce to capture additional information without success. Based on the bug report, the issue was found in a 32-bit Windows JDK 7u25, seems to be limited to 32-bit platforms, perhaps only Windows? Current reaction from Dawid and Vladimir it is a heisenbug, (http://en.wikipedia.org/wiki/Heisenbug <http://en.wikipedia.org/wiki/Heisenbug>). Both Dawid and Vladimir will continue to monitor the situation.