BEA speeds up Java on virtual machines

The system promises to radically increase performance and to give Java the mission-critical, real-time credentials that are needed to turn many organizations away from running C or C++ applications on a farm of redundant single-purpose servers.

Announcing BEA Liquid VM to journalists and analysts in Bali, Indonesia, Guy Churchward, BEA Systems' vice president for engineering, explained that his team came across the solution inadvertently when trying to solve the huge performance hit that came with running Java on virtualized machines.

When an IT department rolls out a traditional solution, they often have to roll it out with one redundant backup in case there is a failure in the main system. This means that CPU utilization rates in the real world are often averaging around 3 to 4 percent with the vast majority of servers sitting there only in case the application gets overloaded

One way to increase server utilization is to run multiple applications on the same machine. However, the problem is that when one crashes it would take the entire system and any other applications running on the same machine down with it. Virtualization solves this by using hardware extensions to trick operating systems that they are each running on their own machine. If one virtual machine goes down, then only that machine goes down and the rest are unaffected.

However, until now, the performance penalty for running Java on virtual machines can be so high that many mission critical users have decided not to pursue virtualization despite the huge savings in energy and data centre space that is promised. Both problems are especially acute in the financial centers of the world such as London. Not only were most of the buildings built in the 1800's, but a 50 millisecond delay from virtualization quirks can cost these companies lots of money when today's systems are engineered to give sub-millisecond response times.

The specific problem is caused when the Java Virtual Machine (JVM--the Java container or engine) decides to do what is called, "garbage collection", or reclaiming unused memory when memory starts to run low. On a virtual machine, this can take tens of milliseconds to do, even on a modern server.

On a physical machine with only one JVM, when the JVM does garbage collection, it simply goes through its memory and throws out unused memory and reclaims it in very little time. However, the problem is that on a virtual machine, with many JVMs sharing the same physical hardware, the unclaimed memory or "garbage" first has to be swapped back into memory by the hypervisor before the JVM can throw it out. This can take tens of milliseconds and worse, it is rather unpredictable as to when the memory situation is so low as to trigger garbage collection.

Churchward parallels it to two people digging a hole with one of the workers throwing dirt across his shoulder into the other person's hole first.

BEA's microkernel operating system, Liquid VM, is essentially a Java Container without the operating system and runs directly on the hypervisor.

"You don't need a general purpose OS to run Java. It's become bloated over the years. You don't need 90 percent of what the OS does. We looked at it, we created code to stretch the JVM down to the hypervisor and the code we wrote is one five-hundredth the size of a general purpose OS," he explained.

The Java Virtual Machine is virtualization from a different point of view than server virtualization though they confusingly share the same word. Java programs can run on any JVM regardless of the underlying hardware or operating system. The same Java binary running on Windows on X86 could also run on AIX on Power. The JVM virtualizes the hardware so the same executable can run on different hardware without having to worry about OS or CPU specific quirks. However, it is a different concept than VMWare or Xen virtualization which involves a super-operating system, the Hypervisor, tricking multiple operating systems that they are each the only operating system running on the same machine.

Getting rid of the OS and the memory it used also means that the IT department can load up even more virtual machines onto one physical server.

Churchward claimed that this was unique as it was virtualization at the Java Virtual Machine level, not the J2EE level. This means that applications based on BEA's own Weblogic as well as other Java frameworks could run on Liquid VM and take advantage of the memory and performance enhancements it offers.

The first version of Liquid VM is now available and offers performance on par with running a JVM on a virtual machine while using up much less memory as the generic operating system (Linux or Windows) is no longer required. LVM 1.1, available around Christmas, will increase performance to that of running solo on a physical machine. In July 2008, BEA promises to launch LVM 2.0 which will offer performance exceeding a physical machine.

This can be done through the closer coupling of JVM and hardware, throwing out the operating system and the 90 percent of it which is not relevant to the JVM, he explained.

Churchward said that the holy grail of virtualization is to have a cloud of servers, an application and a service level agreement (SLA) where the IT manager can throw the application and SLA into the cloud which would take care of providing the right computing resources to run the application at the service level.

Today's service levels are centered only around performance and availability, but soon we will see SLAs incorporate a cost knob and a CO2 or green knob so that IT managers can decide the maximum cost or CO2 levels that a particular software service can consume in that cloud.

Managing SLAs in the virtual cloud is the task of BEA's Liquid Operations Control. This can mange not just virtual machines, but traditional machines as well, or it can aggregate data and pass it on to traditional management platforms such as HP Openview or CA Unicenter.

This control or orchestration is needed especially when SOA is employed. For instance, if a programmer develops a piece of code, for example identity management for single sign on, and offers it as an SOA service, without coordination it would be impossible for the programmer to know how popular the service might become. If everyone in the organization ends up relying on this and the server was overloaded, it could bring the organization down.

Today, BEA's Liquid VM runs only on VMWare, but BEA has plans to offer it on the open source Xensource when and if it reaches a more mature level.

By offering it as VMWare virtual appliance--a freeze-dried snapshot of an installed and running virtual machine, commissioning times can be reduced to almost nothing.