Paul Krill
Editor at Large

Cleaner garbage collector wanted for Java 9

news analysis
Jun 18, 20152 mins

Oracle says the low-pause efficiency in the G1 garbage collector should get the nod over Parallel GC

Plans are afoot to make the G1 server-style garbage collector the default collector for 32- and 64-bit Java server configurations, but there could be complications.

As noted in JEP (JDK Enhancement Proposal) 248, which was first developed earlier this year and updated this month, the motivation for the switch is pause times in memory management. “Limiting GC pause times is, in general, more important than maximizing throughput,” the proposal states. “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, which is currently the default…. The change is based on the assumption that limiting latency is often more important than maximizing throughput. If this assumption is incorrect, then this change might need to be reconsidered.”

The idea is to implement G1 in Java 9, due next year. Many performance improvements were made to G1 in JDK (Java Development Kit) 8 and update releases, with further improvements planned for JDK 9, according to the JEP document.

Oracle documentation positions G1 as a server-style collector targeted at multiprocessor machines with large memories. But becoming the default collector could reveal previously unknown issues in G1, JEP 248 states. “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.” G1 also offers different resource usage. “When resource usage overhead needs to be minimized, a collector other than G1 should be used, and after this change the alternate collector will have to be specified explicitly.”

The parallel collector has been the default for ages in Java, and the Concurrent Mark Sweep collector, intended for applications that prefer shorter garbage collection pauses, also has been an option, said Scott Sellers, CEO of Java Virtual Machine technology vendor Azul Systems. G1 is a newer implementation with cleaner code and easier to maintain by more developers, so “there’s a preference by some to use that as kind of the evolution moving forward,” said Sellers.

But G1 has its downsides, including slower throughput and performance relative to the parallel collector, he said. “Another downside is if an application requires very strict response time characteristics, in almost all cases a well-tuned CMS collector will actually give better response time metrics compared to G1.”

Paul Krill

Paul Krill is editor at large at InfoWorld. Paul has been covering computer technology as a news and feature reporter for more than 35 years, including 30 years at InfoWorld. He has specialized in coverage of software development tools and technologies since the 1990s, and he continues to lead InfoWorld’s news coverage of software development platforms including Java and .NET and programming languages including JavaScript, TypeScript, PHP, Python, Ruby, Rust, and Go. Long trusted as a reporter who prioritizes accuracy, integrity, and the best interests of readers, Paul is sought out by technology companies and industry organizations who want to reach InfoWorld’s audience of software developers and other information technology professionals. Paul has won a “Best Technology News Coverage” award from IDG.

More from this author