Here’s something new to worry about — Java, the programming language widely used in financial 
services — requires warmup time to operate well, a problem that is getting some air time now that Azul Systems has developed a solution which it is promoting.
Although Azul touts the new software, called “ReadyNow!” as a way to avoid problems like Knight Capital’s faulty trading that lost the firm $460 million, it backs away from saying Knight had a Java warmup problem. Indeed, as klockwork explains in a post, citing SEC research, the Knight disaster arose from changes in code that hadn’t been properly tested.
Azul’s CEO, Scott Sellers, backs off linking his software to the Knight issue when he explains that “The types of behaviors that would characterize a Knight Capital is what we are trying to prevent with our technology.”
Almost anyone in a trading, market making and pricing who is using Java, has problems with the warmup Java requires.
Java is the world’s most popular programming language with more than 10 million developers using it, said Sellers, and it is used by 80-85 percent of Global 2000 enterprises. It was designed as a general purpose language, which does create some challenges in the more sophisticated and performance demanding environments, like financial trading, he added.
“While it is generically good, it is not great at some specific areas, especially in financial services.”
Java was designed as a general purpose language, he added.
“Sun created ‘Write Once Run Anywhere.’ Java is different from other languages because a developer doesn’t have to target certain machine configuration when he writes Java code.”
The app itself gets compiled into the underlying instruction set for Windows, Unix, Linux on a server, laptop or mobile when it starts running.
“That is very different from other languages where you target a certain platform as you develop it. The fact that the compilation is just in time is once of the niceties of the runtime environment, but the downside is that it does create some challenges in certain environments.”
Java performs better as it moves along. When it starts, its first goal is to get up and running reasonably quickly, Sellers said, but compilation is a multi-step process.
“There is a tradeoff between how quickly an app starts and how well it can be fully optimized, fully complied and ready to execute trades at full performance level.”
To get around this problem, companies with critical operations, like financial services firms, often run warm-up Java apps with data so the compilation process is optimized before trading begins.
“I need that trading system to be up and running at market open,” Sellers said. Some firms prepare their Java applications by sending fake trades through the application and then stopping them before they execute.
“They have found the best way to warm up the system is to send what look like real trades through it, but because they are synthetic, they are only so good at mimicking a real trade. Every day is different and market conditions are always changing.”
An app that hasn’t fully warmed up can act inconsistently, not exactly a quality one wants in a high-frequency trading or market-making environment.
“You can get hiccups while compilation slows or stops for a fraction of a second. How long the hiccups last depends on the app. In a run-of-the-mill trading platform without a lot of logic associated with it, this may not be bad. Eventually the problems work themselves out.”
Eventually is a long time in high frequency trading with very complex decisions that place thousands of trades and cancel most of them.
“They have very complicated programs behind them, and they can take a long, long time to get fully warmed up, tens of seconds, minutes, maybe even hours. But if you aren’t warmed up in the first couple of minutes of trading, you have a problem. Margins are so razor thin that every you have to make money, and if at 10:09 a major news comes in, and then a whole different level of decisions are made by the trading engine and another code path comes into play — these are really hard problems to solve.”
The problem is technical , but the solution has been to throw people at it, and that is slow and expensive. Azul’s ReadyNow! built into Zing, Azul’s runtime for Java, offers a technical solution.
OptionsCity, an Azul client, looks forward to using ReadyNow! said Victor Glava, the company’s CTO.
“OptionsCity builds trading apps for professional traders,” he said. “In our kind of field, low latency and high throughput are a requirement. The language is Java, which offers many benefits, but they do come at a cost. One of things it offers is memory management which you don’t have in C++. Java does memory management for you but at a cost — garbage collection pauses come into play and it needs to reclaim memory that is not used by the application. For regular Web sites, this is not a problem — millisecond pauses, if you are browsing information on a Web site don’t matter, but for financial apps, milliseconds can be an eternity.
“The Java environment takes steps to optimize its performance. As the JVM is running, it identifies pieces of the code that are hot and being used a lot and basically optimizes them.”
When the trading day opens it is fast and furious right away, said John Rymer, a principal analyst at Forrester Research.