Upstart $3bn forex trader dumps Oracle JVM for Azul's Zing

Financial services companies were among the early and enthusiastic adopters of Java - but the jittery Java virtual machines from Oracle and IBM (and others before Oracle ate them) have been a pain for some. Azul Systems is hoping to cash in on that grief among big banks, brokerages, high frequency traders, and others in …

[Destroy All Monsters]

It's Syndrome, and he's using his Zero-Point Energy Beam to Trade!

Yah Very Nice

... but can one do something useful with it except try to mint dollars from brownian motion?

[TheVogon]

Re: It's Syndrome, and he's using his Zero-Point Energy Beam to Trade!

All this trouble when they could just code in F# or C# / .Net and completely eliminate this problem - and get lower latency / faster performance too...

[David Martin]

Re: It's Syndrome, and he's using his Zero-Point Energy Beam to Trade!

Oh, the CLR doesn't need to do garbage collection does it?

The fact that the JVM offers a choice of implementations is the very reason why companies have the option to switch to another one with more advanced GC strategies

[TheVogon]

Re: It's Syndrome, and he's using his Zero-Point Energy Beam to Trade!

Sure .Net does GC, but it does it in a far less impacting way - completely in the background, and non blocking - unlike in Java: http://blogs.msdn.com/b/dotnet/archive/2012/07/20/the-net-framework-4-5-includes-new-garbage-collector-enhancements-for-client-and-server-apps.aspx

.Net offers a choice also - Mono is perfectly serviceable.

What you really mean is that Sun Java sucks, and you have to spend lot of money if you want a version that actually works well....

[Enet Lig]

Re: It's Syndrome, and he's using his Zero-Point Energy Beam to Trade!

Seriously Vogon? You interpret "... resulting in much shorter (less noticeable) pauses. One customer reported a 70% decrease in GC pause times." [quoted straight from your linked .NET article] to mean "Completely in the background?".

[Michael Wojcik]

Re: It's Syndrome, and he's using his Zero-Point Energy Beam to Trade!

Sure .Net does GC, but it does it in a far less impacting way - completely in the background, and non blocking - unlike in Java

What a load of fatuous, handwaving bullshit (though we expect no less from a known troll).

The last time I checked,[1] the CLR offered exactly two GCs, "workstation" and "server", which were both respectable generational collectors, tuned for different workload classes, but nothing remarkable.

As of .Net 4, neither GC does concurrent collection by default, and only the workstation GC supports it at all. And both GCs block processing threads (when they try to allocate from the heap) during collection when they run in non-current mode. And the server GC schedules multiple high-priority GC threads per core, so even its background mode can block processing threads simply through preemption.

What you really mean is that Sun Java sucks, and you have to spend lot of money if you want a version that actually works well

Clearly what you really mean is that you have no idea how GC works. Different collectors are optimized for different workloads. There are relatively few classes of workload where you want consistent GC overhead; usually bursty GC overhead is better, either because the typical applications you're running never need to do significant GC, or because they're interactive and have significant "think time" where the JVM is otherwise idle anyway. There's no single optimal real GC behavior - that's why .Net offers two collectors, and those with multiple modes.

Azul's C4 is well-suited to workloads like trading where you want consistent behavior across a huge number of short-lived transactions, but it's not particularly good for, say, retail banking or insurance applications (another big area for Java), or for running Eclipse, or for UIMA-based text processing, etc. And, as others have pointed out, it's not the first consistent-GC JVM either. Horses for courses.

[1] I can't get to the blog post you cited at the moment - though I'm pretty sure I've read it before anyway - but there are any number of other MSDN pieces on CLR GC, such as this one.

[Anonymous Coward]

Re: It's Syndrome, and he's using his Zero-Point Energy Beam to Trade!

Not only does this approach not completely eliminate the problem, it introduces the problems of increased development and maintenance costs.

But traders shouldn't be using the standard JVMs anyway, if they are they are pretty stupid. Both Oracle and IBM have real time versions of the VM's for just this sort of usage, it's nothing new.

[giltene]

Re: It's Syndrome, and he's using his Zero-Point Energy Beam to Trade!

Real time is not about speed - it's "slow and steady", and never missing a deadline. As such, real time JVMs tend to make design choices (like non-contiguous objects and many de-references on accesses) that lead to typical latencies that can be much worse (as in 10x) than server JVMs, but they will guarantee an absolute worst case. A real time JVM may be what you want your heart pacer to run on (if you wanted Java in a heart pacer), but it's certainly not what you'd want a trading system or a trading venue to be executing on when what you care about is both speed and consistency.

[CadentOrange]

High performance Java

I've been to a number of presentations by the LMAX guys and these guys know what they're talking about when it comes to extracting performance from the underlying hardware. They're Disruptor design pattern is interesting and I've adopted it with much success. For a financial company, they're very open about the technology they use. http://mechanical-sympathy.blogspot.com is a blog by one of their developers that I've got bookmarked.

[Anonymous Coward]

Re: High performance Java

I've been to presentations by the LMAX guys too and the thing I find interesting is that they have a need to improve GC jitter. As well as mechanical sympathy, a core design feature of the pattern is the ring buffer of pre-assigned objects, designed to make objects in it effectively immortal, so it's interesting that they have any GC issues.

[erik svensson]

Re: High performance Java

The disruptor should really be used with primitives only, not complex types since that will increase the gc:s needed. And it's not the disruptor per se that is causing the gc:s, it's the rest of the system.

The disruptor and the lmax guys are running so far out in the performance envelope that even normal minor gc:s induce jitter in their latency.