Azul Prime cuts Java warm-up times with new compiler

Azul has added a feature to Azul Prime that it says cuts Java application warm-up times by 2x to 5x compared with standard OpenJDK. The update centres on sharing optimisation data across Java Virtual Machines.

The feature uses Azul's Cloud Native Compiler to stream compiled code from existing deployments to new application instances at start-up. As a result, new instances can begin with code already optimised elsewhere in the same application fleet, rather than building those optimisations from scratch as they process live traffic.

Java warm-up has long been a challenge for organisations running large application fleets in cloud and container environments. In a conventional setup, each Java Virtual Machine independently learns which parts of an application are used often enough to justify just-in-time compilation. That can leave newly launched instances running less efficient code until enough activity has passed through the system.

Azul says this pattern has become more costly as companies rely more heavily on autoscaling and deploy code more frequently. It cited industry data showing broader use of Kubernetes autoscaling and rising CPU overprovisioning, which can increase infrastructure spending when teams maintain extra capacity to cover slow starts.

How it works

The addition builds on earlier Azul products designed to reduce warm-up delays. In 2014, it introduced ReadyNow to address warm-up for individual Java Virtual Machines in latency-sensitive workloads, then later expanded that approach with ReadyNow Orchestrator, which learns and serves optimisation profiles across an application fleet.

Cloud Native Compiler extends that model by sending what Azul describes as fully optimised compiled code to new instances at start-up. The system predicts what code a new instance is likely to need based on previous starts across the same fleet and installs those optimisations before the instance begins handling requests.

According to Azul, the feature does not require applications to be rewritten, recompiled, or re-architected. It is enabled through configuration within Azul Prime and is included at no extra charge.

Cost pressure

Azul argues that faster warm-up could change how Java applications are run at scale. Teams often keep spare instances available to absorb periods when new application instances are still warming up, or accept temporary latency after deployments and during demand spikes. If new instances become productive more quickly, operators may be able to reduce standby capacity and rely more on dynamic autoscaling.

This could affect both cloud spending and service performance. In sectors where systems are expected to respond at full speed from the first request, slower starts can affect transaction processing, user response times, and service stability during redeployments or traffic surges.

Azul cited fraud detection, digital payments, real-time advertising, multiplayer gaming, and eCommerce as examples where first-request performance matters.

Partner angle

Azul also framed the update as an opening for channel partners. Resellers and service providers could use the feature in professional services and managed deployments to help customers lower infrastructure use without changing existing Java applications.

Scott Sellers, Co-Founder and Chief Executive Officer of Azul, said the issue had long been treated as an unavoidable part of running Java systems at scale.

“Teams have lived with slow JVM warm-up for so long they treat it as a given, over-provisioning and avoiding autoscaling just to hide it,” said Scott Sellers, Co-Founder and Chief Executive Officer of Azul.

“Azul Prime with Cloud Native Compiler fixes that. A new application instance inherits the compiler optimisations its fleet has already learned and executed instead of starting cold. You stop paying the warm-up tax on every single instance, thereby slashing the time required for a given application instance to reach its full performance.”