Virtualizing the JVM

Perhaps I was a bit too sneery Monday about the newly stacked set of Java and other components that Oracle recently rolled out under the "WebLogic Suite Virtualization Option." While the product may not denote the end of the operating system, the JRockit Virtual Edition VM at the heart of it is in fact running directly on the Oracle VM hypervisor, rather than on some virtualized OS. Oracle VM still needs an OS to run on, of course, but I imagine the goal is to frame that underlying OS as a "commodity" that you can run on whatever servers you've cobbled together in your data center (or, excuse me, "private cloud").

Alex Barrett at has a pretty good sum-up of what WebLogic Suite Virtualization Option is and does, including an intriguing discursis on the product's history. (It originated as a pre-Oracle BEA project, and was originally designed to work with VMware's offerings.) The key paragraph, for me, is this one:

JRockit Virtual Edition derives from Liquid VM, the virtualization-friendly JVM from BEA, and handles traditional operating system functions such as TCP/IP, hardware device interaction, file I/O and process scheduling. In this way, JRockit eliminates OS overhead not needed to run a Java application. This delivers improved performance of about 33% compared with Java applications running on an OS, said Steven G. Harris, Oracle senior vice president of product development.

The whole concept is kind of head-spinning to me -- after all, the whole point of the Java Virtual Machine is that it's, well, virtual, and this seems to be adding another layer of virtualization into the mix. But upon further reflection perhaps the way to look at is that at least one layer has been removed -- after all, we could be looking at a scenario (which I'm sure somebody somewhere has implemented) where a JVM is running on an OS which is running in a hypervisor which is running within an OS which is running on an actual physical machine. Here the hypervisor itself is offering the functionality that Java programs need to run, which is a neat trick. What confuses me a bit is that 33 percent figure -- does that mean 33 percent faster than a Java application running on the rickety stack I just described, or 33 percent factor than a Java application running on an unvirtualized OS.

At any rate, Barrett goes on to describe the cost and licensing headaches that potential customers foresee that might keep them from shelling out for WebLogic Suite Virtualization Option. I do wonder if this will be the first of several offerings along this line -- will SpringSource/VM be able to pull off something similar?