As previously mentioned on InfoQ, Oracle had proposed JEP 248, about making G1 the default garbage collector, to be included in the list of JEPs targeting Java 9; recently, Oracle has confirmed such decision and made it official. The decision triggered a lengthy debate in the HotSpot’s email discussion list, which concluded with a provision to defer the change if G1 proves not to be fully ready.
One of the main points in the discussion was centred on understanding the population of applications that would be affected by this change. As indicated in the JEP, the change is aimed at “the default garbage collector on 32- and 64-bit server configurations”. Server configurations, also known as server-class machines, refer to machines that count with at least 2GB of RAM and at least 2 hardware threads. Any machine with a lower specification is considered a client-class machine, and they will be unaffected by this change: client-class machines will continue to use the Serial Garbage Collector by default.
On the other hand, this JEP doesn’t modify the list of garbage collectors available within the JVM, it only changes the one that will be picked when the user doesn’t explicitly choose one. In other words, all Java applications where the user indicates through the command line the garbage collector that is to be utilised will also be unaffected. This means that the population of affected applications will be those running in server-class machines where the user hasn’t explicitly specified the garbage collector to be used.
Ben Evans, co-founder of jClarity, ran an informal survey within the London Java Community which showed that approximately 40% of all survey respondents are currently using the default garbage collector. Although the sample size may not be large enough for this to constitute hard evidence, it provides an anecdotical view of the proportion of applications that could be affected by the JEP. With this into consideration, the next point of discussion was centred on how this set of applications could be impacted.
Concerns around how the change could impact the target population came around two areas: a potential degradation on the out-of-the-box behaviour (for the cases where Parallel GC provides better performance than G1 GC), and the potential presence of bugs on G1 due to it not being sufficiently field-tested. The first point was considered a lesser issue by Oracle, with Charlie Hunt, JVM Performance Lead Engineer at Oracle, arguing that “if a GC is not explicitly specified at the JVM command line, then tuning GC may not be important for that application”. This argument, however, wasn’t entirely accepted by the community.
The second point, the necessary testing strategy to validate G1, also caused a division of opinions. The view within Oracle seems to be that making G1 the default garbage collector while Java 9 is still under development would give it the necessary extra exposure to uncover any unknown issues, and therefore have a sufficiently refined product in time for Java 9 General Availability in September 2016. This argument caused some additional concerns though, since the community is already being relied upon to test other important Java 9 initiatives like HTTP 2.0, Project Kula and parts of Project Jigsaw. In the end, a compromise was chosen, and Stefan Johansson, owner of JEP 248, added the following clause to the proposal:
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.