Coordinated Restore at Checkpoint (“CRaC”) is now generally available in Azul Zulu 17 with CRaC support for Linux x86 64-bit.

ReadyNow!® Start Up Faster
and Stay Fast

Before and After ReadyNow!

Behind the Java warm-up problem

Java-based systems deliver great performance when running compiled and optimized code. However, the JVM needs time to “warm up”, or optimize frequently-used code, so the application can run at top speed. Why does this happen? Java was designed to start up quickly, then improve performance over time based upon actual usage. The JVM’s just-in-time (JIT) compilers (like Azul Platform Prime’s Falcon compiler) depend upon profile data that describes which parts of the application are called the most (the “hot” code). JIT compilation allows the JVM to optimize performance, but it can take time. In use cases like capital markets, typically systems are “warmed up” to deliver peak performance. While a Java application often can take time to start up, it has to be ready to go and fully optimized when the opening bell rings.

Solving the Java warm-up issue 


Designed for Java-based applications that must meet specific service levels


Helps developers manage Java’s runtime de-optimization


Reduces CPU resource consumption


Allows accumulated compiler optimization profiles to be saved and re-used


Provides developers with more control over Java compilation


Reduces operational warm-up risks caused by the need for synthetic tests or “fake” data


Ensures consistent, peak performance during critical times like market open


Allows Java to start up fast and stay fast

Current Java warm-up strategies

Companies requiring optimum Java performance and consistency such as those in financial services have tried a number of ways to warm up the JVM such as simulated test data, “fake” trades, or even bursts of small live trades right at market open. Among other issues, these strategies can introduce an operational risk that “fake” data might leak through into the “real” trading day or that actual conditions may differ from the scenarios used to warm up the JVM. Effective strategies need to replicate the real end-to-end behavior. Java reverts to interpreted code if conditions change, a condition called “de-optimization”, that slows performance to a crawl until key methods are recompiled and re-optimized. Azul’s ReadyNow! technology provides two key functions. The first is the ability for operations teams to save and reuse accumulated optimization profiles across runs.  The second is a robust set of APIs and compiler directives that give developers more control over the timing and impact of JVM de-optimization.

The Solution: ReadyNow! technology from Azul Systems

ReadyNow! is technology built into Azul Platform Prime. It allows essential systems to achieve optimum performance and consistency at the start of the trading day. Where common warm-up techniques may sometimes optimize for the wrong conditions, Azul Platform Prime’s ReadyNow! technology prevents most de-optimization that otherwise would occur when “real” trades differ from the profile used for warm-up. With ReadyNow! operations teams can save accumulated optimizations from one day or set of market conditions for later reuse.  Plus, developers gain more control over Java compilation, including APIs, configuration directives, policy controls and improvements to “unreached” code handling. Designed for low latency systems, ReadyNow! technology makes Java applications market-ready fast from the opening bell — and they stay fast.

Learn about all the benefits of ReadyNow! technology.

ReadyNow! is ideal for market-facing systems challenged by warm-up issues. Contact Azul to learn how ReadyNow! can accelerate your operations at market open and deliver predictable, low-latency performance when you need it most.