In financial markets, trading strategies are becoming ever more sophisticated and complex, yet still must execute quickly and consistently. This is a growing concern to traders seeking to gain a competitive advantage based on strategies that require large volumes or complex datasets. Unfortunately, strategies often stumble, or fail, due to poor execution consistency during the trading day.
Here’s one example. For many years, Java application owners have grumbled about an industry-wide practice called “warm-up”. “Warm-up” attempts to overcome a strength of Java that sometimes is a weakness for traders – that fact that performance improves over time as the Java Virtual Machine’s (JVM’s) compiler ‘learns’ which code is used often and re-compiles it for faster execution. By running a Java application with fake data or small bursts of simulated trades for a while before the market opens, firms try to achieve optimum performance leading up to the first ‘real’ trade. However, these practices do not guarantee the desired results, they introduce operational risk of the warm-up data leaking into the trading day, and execution during the trading day can still be inconsistent as conditions change from those used to warm-up the system.
To understand why warm-up is prevalent in trading and other real-time systems let’s take a closer look at Java. As a language it was designed to start up quickly and improve its execution over time. This made sense for desktop applications and enterprise servers, where systems needed to be up and running quickly then operate for long periods of time under stable conditions. However, for low latency and real-time applications, the warm-up and de-optimisation (part of the time when the JVM compiler re-compiles certain code to make it even faster) periods can be very costly. In these systems, revenue and profit depend on lightning-fast execution at critical times such as when markets open or news stories break.
In algorithmic trading, the JVM often doesn’t optimise the “right” code because applications gather and process information at high rates but trade relatively infrequently. The code that really has to be fast – the trade – is often not optimised, at least not for a long time after startup. If trading is slowed, even by a few milliseconds, the opportunity for profit may be lost. For financial markets, it’s ok to take a longer time to start up, since teams can plan around market open. But, once the market opens, the first real trades have to be processed at full speed. A learning cycle after market open (even a fairly short one) or when conditions change during the trading day is not good enough. Legacy JVMs also lose all the accumulated compiler optimisations any time it is shut down, so what the system “learned” in making optimisations in yesterday’s trading can’t be used to jump start trading operations today.
The solution for warm-up is twofold. On the application side, development teams need compiler controls – they need to be able to tell the compiler which code has to be fast when it runs, even if it isn’t run very often. On the operations side, the JVM needs to be able to save accumulated optimisations across runs, so firms can ‘jump start’ the Java compiler for market open or other significant events without running fake trades. With these two modifications, the JVM can start fast and stay fast without adding risk or causing costly de-optimisation slowdowns during the day.
Azul’s Zing®, with its ReadyNow!™ capability, helps solve the Java “warm-up” problem and ensures peak application performance is available without long “warm-up” periods and during other critical times. Zing delivers the holy grail of solution to the Java warm-up problem – it enables performance optimisation settings and learned compiler decisions from prior application runs to be available at application startup and restarts.
This unique capability of Zing enables Java applications to reach their full performance profile dramatically faster (without the slowdowns associated with typical Java compilation processes) and also substantially reduces variability in runtime performance and latency. With Zing, developers and operations teams can finally take control of application performance and stop worrying about the unpredictable performance associated with traditional warm-up time.
According to John Abbott, Distinguished Analyst at 451 Research, “Azul’s Zing JVM remains one of very few options available for customers requiring the maximum performance and consistency from a Java runtime. The ReadyNow! feature in Zing significantly extend the core low-latency and garbage collection capabilities that support the most demanding business applications, such as those in the financial, eCommerce, and telecommunications sectors.”
As Java continues to be used more and more in low latency and real-time systems, the JVM needs to evolve to support new requirements for fully optimised performance from start to finish. It’s no longer acceptable for applications in trading, fraud detection, eCommerce and many other areas to deliver sluggish performance at the most critical times. By deploying Zing, your systems can start fast and stay fast and ultimately improve your bottom line.
By Scott Sellers, CEO and Co-Founder, Azul Systems