News

Oracle Considers G1 Garbage Collector for Java 9

• By John K. Waters
• June 22, 2015

Oracle Corp. has proposed making the Garbage-First (G1) Collector the default HotSpot garbage collector (GC) in JDK 9 on 32- and 64-bit server configurations, sparking some debate in the Java community on the pros and cons of G1 versus another supported GC: the Concurrent Mark Sweep (CMS) Collector.

Introduced in JDK 7 update 4, G1 is an incremental parallel compacting GC that provides more predictable pause times than Parallel GC, which is the oldest and current default HotSpot GC for server configurations. Parallel GC was designed to maximize application throughput by allowing occasional stop-the-world (STW) pauses.

"Parallel GC is hardened, robust, and the most stable of the three," explained Scott Sellers, CEO of Java runtime maker Azul Systems. "If the only thing an app cares about is absolute performance, Parallel is always going to give you the best results, because it's not doing any incremental garbage collection. It lets the app run, untethered, as fast as it possibly can, but then, from time to time, it freezes the application to do garbage collection. But the result is this sawtooth pattern of performance."

Proponents of G1 argue that limiting GC pause times is more important than maximizing throughput. As Oracle explained it on the Java Enhancement Proposal (JEP) 248 project page, "Switching to a low-pause collector such as G1 should provide a better overall experience, for most users, than a throughput-oriented collector such as the Parallel GC ...."

But fans argue that CMS was introduced essentially to solve the same problem as G1. CMS is also a low-pause GC that can reclaim memory while the application is running, though it still requires some STW pauses. Oracle says it was "designed for applications that prefer shorter garbage collection pauses and that can afford to share processor resources with the garbage collector while the application is running."

"CMS came around to address the most severe STW pauses," Sellers said. "And it has evolved literally 100-plus controls that allow people who run Java applications to tune it to achieve various results. It's the predominant collector today used with HotSpot for those applications that actually care about response time."

But CMS still requires the occasional STW pause, there's a one-to-one correlation between the amount of heap space used by the application and the pauses, and it requires tuning, Sellers said. G1 was developed to improve the out-of-the-box latency characteristics of CMS with no tuning, but performance will be slower. "G1, in almost all cases, will not give as good a latency profile as a well-tuned CMS," Sellers said. "So for those who really know what they're doing, CMS is still a better collector than G1." But G1, by virtue of being newer, almost certainly has the cleaner code base, which makes it less fragile and difficult to evolve and maintain.

CMS users fear that making G1 the default GC in JDK 9 signals a future deprecation of the GC, Sellers said. Although no one seems to be talking about deprecating CMS any time soon, on its G1 tech page, under the subheading "Future," Oracle says: "G1 is planned as the long term replacement for the Concurrent Mark-Sweep Collector (CMS)."

Oracle has added JEP 248 ("Make G1 the Default Garbage Collector") to its JDK 9 project page as a potential addition to its "JEPs targeted to JDK 9" list, and pointed Java community members to the JDK 9 and HotSpot mailing lists to discuss the idea.

In other words, making G1 the default in JDK 9 is not a done deal. "G1 is seen as a robust and well-tested collector," the JEP 248 page advises. "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."

"By proposing G1 as the default, Oracle is clearly saying that, for the broadest spectrum of apps, response time absolutely matters," Sellers said. "If it didn't, then Parallel GC would be the way to go—which validates something that Azul has been saying forever."

Azul's flagship product, Zing, is a Java Virtual Machine (JVM) based on Oracle's HotSpot JVM. It's a no-pause JVM designed to eliminate GC pauses. This pauselessness, which Azul calls "generational pauseless garbage collection" (GPGC), enables Java app instances to scale dynamically and reliably. Azul has long targeted GC, which Sellers has called the Achilles heel of Java.

JEPs are similar to Java Specification Requests (JSRs), which are submitted to the Java Community Process (JCP). JEPs allow Oracle to develop small, targeted features for the Java language and virtual machine outside the JCP, which requires full JSRs.