Cleaner garbage collector wanted for Java 9

18.06.2015
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."

(www.infoworld.com)

Paul Krill

Zur Startseite