Platform Prime: Azul Prime (Zing) Builds of OpenJDK

We run a large in-memory data grid to store millions of customers -- clusters of up to 30-40 JVMs, each with ~90GB heap, deployed across a variety of infrastructure including Azure, AWS, and on-prem. Azul Zing avoids full GC impact, giving us better latency and higher throughput for our online charging system.

With non-Azul JVMs we saw frequent crashes, CPU spikes, and hangs from stop-the-world GC pauses. With Zing, GC-related incidents are almost zero. We get lower transaction latency and cost savings — same TPS with fewer machines, which cuts our cloud (EC2/Azure) spend significantly.

The best features Azul Zing offers include no stop-the-world during the full GC.

No stop-the-world pauses during full GC, and we hit higher TPS with fewer JVMs -- a real win for maintenance and cost. As an online charging system, we can't afford crashes or latency spikes. Before Zing, JVMs would hang and drop from the grid on missed heartbeats. GC tuning is also out-of-the-box -- no more time consuming  manual tuning like with Oracle/OpenJDK with no significant outcome.

Nothing major, but one nuance: Zing auto-adjusts internal config based on available CPUs, which can cause brief CPU spikes every few minutes. These are harmless, but can give ops/monitoring teams a false alarm. Better visibility or documentation on this behavior would help.

I have been using Azul Zing for more than six years.

Very stable. Before Zing, we faced frequent JVM crashes, hangs, and CPU spikes from stop-the-world GC pauses, requiring planned restarts every few days just to avoid unplanned failures. Since moving to Zing, that operational overhead is gone — incidents are almost zero, and our JVMs stay up reliably across 30-40 node clusters running 24/7 for our online charging system.

Scalability has been excellent. We run clusters of 30-40 JVMs, each with ~90GB heap, across many productions of varying sizes on AWS, Azure, and on-prem. We've never hit a scalability limit with Zing — it consistently handles our growth in TPS and customer volume without needing to add more JVMs, which also keeps our infrastructure and licensing costs in check.

Excellent. Support is just a mail away — they respond quickly, and queries are handled in a friendly, down-to-earth way. You don't need to be deeply technical to get help; they meet you where you are and resolve issues efficiently.

Yes, we previously used Oracle JDK/JRE and OpenJDK. We switched due to full GC stop-the-world pauses causing crashes, latency spikes, and operational pain (planned restarts, constant GC tuning)

Initial setup was mostly straightforward — well documented, and licensing was simple. Some tuning was needed initially, but notably not GC parameter tuning, which was a big relief compared to Oracle/OpenJDK where GC tuning was a constant, ongoing effort. Overall, a smooth transition with minimal operational burden.

Yes, clear ROI. We achieve the same TPS with fewer JVMs/machines than before, directly cutting cloud infrastructure costs across AWS, Azure, and on-prem. We also eliminated the manpower spent on planned JVM restarts every few days, and reduced production incidents and night-time support calls significantly. Given we run this across many productions, large and small, the savings compound.

Setup cost isn't significant, the documentation is clear and straightforward, and licensing is simple. I'm not directly involved in pricing negotiations, but given we run it across many production environments, both large and small, I'd consider it affordable with a strong ROI.

9/10 — for a real-time system, GC pauses aren't acceptable, and Zing solves this out-of-the-box. It eliminated planned restarts, cutting operational overhead and night-time incident calls dramatically. One note: on JVM startup, deoptimization causes higher CPU utilization for the first few seconds — worth knowing but not a real problem.

My advice: if you can't afford full GC pauses, JVM hangs, or latency spikes, go with Zing.