Oracle Java virtual machine slows high frequency trading, says Azul CEO
This Achilles' heel has to be addressed
By Matthew Finnegan | Computerworld UK | Published: 11:38, 18 June 2013
As the technology arms race continues in high frequency trading (HFT), Oracle's HotSpot Java virtual machine (JVM) is presenting a barrier to the development of ultra low-latency applications, according to Azul Systems' CEO.
High frequency trades are conducted using computer algorithms to buy and sell huge volumes of shares for small individual gains at a fraction of a second. In order to beat competitors to trades, HFT companies are engaged in an ongoing race to improve the speed of their IT and communications systems, shaving milliseconds off trade times as they move towards the Holy Grail of zero latency.
"The whole idea of high frequency trading is to make money, grabbing pennies or micro-pennies hundreds of thousands of times over, and then aggregate those very small profits over and over again to make a lot of money," said Scott Sellers, CEO of Azul Systems. "If a firm is not able to complete all of that in a certain amount of time they may lose that opportunity to a guy across the street. So speed is everything in the world of HFT."
Related Articles on Techworld
According to Sellers, one of the stumbling blocks trading firms face in increasing trade speeds is the use of the Oracle HotSpot JVM in their bespoke applications. His company markets products designed to address this.
Java is used on nine million servers in the world, the majority of which use Oracle's HotSpot system to process the code, with Azul one of the competitors in the market with its own Zing JVM. But while Sellers believes that Oracle's JVM is adequate for the majority of processes that Java is used for, he argues that the programming language can result in a bottleneck when there is a need for ultra low latency, such as in HFT markets.
"For the majority of the Java market where performance or latency isn't critical, Oracle's HotSpot JVM is fine," Sellers said. "However, in the very high performance segment of the Java market, HotSpot is not sufficient."
Sellers said that Oracle's JVM, introduced over a decade ago, was not originally designed to keep pace with the speed increases demanded by trading firms in recent years. As latencies for trades have fallen from tens of milliseconds into the single digit millisecond bracket or lower in some cases, response time inconsistencies in the JVM mean that a small number of trades will be delayed, he said.
Although these latency outliers occur infrequently, and may add mere milliseconds to trades, such small delays can be massively disruptive to trading strategies, Sellers said. So while Oracle's JVM can achieve single digit millisecond latencies, the average speed still affects the overall performance of HFT applications.
"Some 99 percent of trades may complete with single digit millisecond latency, but one percent complete with tens if not hundreds of milliseconds of latency," Sellers said. "This is a real problem in the world of HFT, because that one percent difference in terms of trades losing money can ruin an entire strategy."
Sellers said that inconsistencies are one of the problems with the Java language when compared to other programming languages such as C++, which has benefits for low latency, mission critical applications.
However Sellers argues that Azul's Zing JVM is able to elastically scale memory usage to compensate for Java garbage collector latency outliers, and believes that the programming language is set to remain the prominent platform for HFT in future, as others fall by the wayside.
"The reality is that C is turning into this generation's COBOL," Sellers said. "It is extremely difficult to find quality C programmers in this day and age. Just like COBOL a decade ago, there was an industry crisis around finding COBOL programmers to keep these mainframes up and running. The same is now happening with C and C++."
He said that despite problems with Java, advances in recent years have meant that it is on par with C in areas where it has previoulsy lagged: "In terms of absolute performance - such as the number of trades per second on a given server - the difference between Java applications and C based applications is almost indistinguishable. It is just this Achilles heel in terms of response time consistency that has to be addressed in the context of HFT."