This week’s JCP meeting was coincident with a series of press articles and commentary around a proposal within the OpenJDK community to make G1 the default garbage collector for Java 9.
As Azul is the recognized leader in Java garbage collection technology, many people asked for our opinion.
From what we hear from our customers and our own internal testing, G1 has lower application performance/throughput than Parallel GC (the default GC today), and has worse latency profiles than a well-tuned CMS collector. Often times, G1 does have the benefit of having better “out of box” (i.e. un-tuned) latency profiles than CMS. While G1 can be tuned, there are much fewer options and tuning knobs in G1 than CMS, which is why an experienced user can typically tune CMS better to meet the latency profile needs of a specific application.
So really G1 is a “tweener” – slower than Parallel GC for those applications which only care about performance (with no regard to latency profile) and worse than CMS for those highly tuned, latency-sensitive applications.
Regardless of which garbage collector the OpenJDK community ultimately decides is the best default, Azul’s C4 collector in Zing is clearly the best of all. C4 reflects more than 10 years of real-world use in the most demanding mission critical deployments, delivers orders of magnitude (no exaggeration!) better latency profiles, has great throughput, and requires minimal tuning. C4 is the foundation of the continued rapid adoption of our Zing JVM across enterprises worldwide.
So, your choices are simple. You can watch your applications randomly pause, frustrating your customers and breaking your SLAs, and spend costly man-hours trying to tune and workaround the problem — or you can run Zing, a JVM that has effectively solved all of Java’s GC problems and use your previous developer time adding real value to your business.
See for yourself — get started by trialing Zing with your application. It all begins with a simple request: www.azul.com/zing/trial.