Souped Up Java with Azul: Part II
Souped Up Java with Azul: Part II
Join the DZone community and get the full member experience.Join For Free
Sensu is an open source monitoring event pipeline. Try it today.
Sellers said that when Azul first started working on their Java acceleration tools, obviously they didn't want to re-invent the wheel when it came to the JDK's class libraries and other things. So they licensed Sun's Hot Spot JVM as a starting point from which they could enhance the JVM to run on the Vega microprocessor. The Vega's hardware is specifically designed accelerate Java applications and it provides special hooks that address the limitations of off-the-shelf hardware. Azul has tackled the limitations of the JVM with both hardware and software.
Cliff Click's work on Azul's overall JVM has been the real secret behind the company's success with customers like saks.com. Their website claimed first place in the Gomez high-broadband availability tests for November 2009. "Dr. Click is a true rocket scientist in this area of Java Runtimes," said Sellers. Click and his team has vastly improved the overall value of the JVM by fixing garbage collection issues and adding deep, fine grain visibility into running Java applications with no performance hit whatsoever.
Dr. Click's team has also been able to virtualize a running JVM, meaning that Azul can offload an application off of a SPARC platform for example, and the application would have no knowledge that its not still running on SPARC. It's a like a NetApp filer, said Sellers, where storage is no longer sitting inside the server but instead is sitting on a network-attached storage device. "The application accessing the storage has no idea that NFS access is no longer in a box, it's over a network," said Sellers. "In our case with Java, the application still thinks it's running on that Sun box, and the systems surrounding that existing Sun box also think it's running on that Sun box, however, in actuality it's running on the Azul box, but it's all virtualized." That kind of virtualization allows unmodified applications to run on any environments including Solaris, Linux, AIX, HP UX, and even zLinux.
At the lower levels of Azul's JVM, Dr. Cliff, an expert in compiler technology, has improved the Java server compiler's performance and instrumented code. Sellers explains that Azul's JVM has a tiered compilation system that balances the need for quick startup time and has excellent overall performance. Dr. Click has also done a lot of work that allows the JVM to scale much more effectively in terms of thread count. "Today's systems typically are dealing with single digits to low double digit numbers of threads per JVM instance," said Sellers. "Our 14U [chassis] appliance has 864 individual processors in it," said Sellers. "So you can literally have a single JVM scale to 800-plus processors using 800-plus threads for a huge amount of horsepower within a single JVM instance." When you try to scale to that level on generic server hardware, then the classic limitations associated with multi-threading and serialization events around locks limit the scalability, as described by Amdahl's Law. Azul has developed a number of techniques and patents around speculating past locks and allowing parallel threads to continue to do work even in the presence of locks that would stop an off-the-shelf server.
DZone asked Sellers what he thought about Oracle's plans to integrate technology from HotSpot and JRockit, and their plans to run the JVM natively on hypervisors. On JRockit and HotSpot, Sellers said, "From our perspective, those JVM's are very similar in terms of how applications run on them." It doesn't matter to Azul whether the two code bases merge or not. "Our Java technologies and our solutions are years ahead of either one of them," said Sellers. He says its unclear how a merger of HotSpot and JRockit would benefit the customer because there's very little difference between the two.
However, Sellers does think Oracle's work with running the JVM on hypervisors is interesting. "It seems to be coming out of the work that BEA did before the Oracle acquisition," said Sellers. BEA's solution however, was not transparent, so the types of Java applications that could run on a hypervisor were limited according to Sellers. "What we do, by offloading Java away from traditional operating environments, is we remove the limitations of the traditional operating systems. That's the theme that Oracle is also talking about," said Sellers. "It's this idea of bypassing the legacy OS. It's nice to see Oracle agreeing with our vision of bypassing the OS; that's what we've been doing for the last seven years, so we welcome them to the party."
In the first part of this interview, Scott Sellers discusses the limitations of the Java runtime and how, in spite of those limitations, his company helps deploy enterprise-level Java workloads that scale well and perform at a high level whatever the load.
Opinions expressed by DZone contributors are their own.