Virtualize Java without an Operating System

“Virtual Machine” seems to have two distinct meanings:

• Sysadmins deal with “system” virtual machines, i.e. guest operating systems running on a VM host.
• The application programmer generally deals with a “process” virtual machine, such as
  • the Java Virtual Machine
  • the Common Language Runtime (CLR) for .NET

The “process” virtual machine may be running on an operating system which (in turn) may be running as a “system” virtual machine on a VM host.  So, in some sense when we put a .NET application on Windows on Hyper-V (or a Java application on Linux on ESXi) we are actually virtualizing twice. The question arises as to whether we can actually virtualize only once, by putting the CLR or the JVM directly on the VM Host.  In this action of course we remove the operating system.

We’ve mentioned this before at the Virtualization Practice, and there are actually two parts to the question

1. Which vendors are motivated to do remove the operating system?
2. Is this technically feasible?

So, to answer the first question it is fairly clear that if you are making a substantial proportion of your revenues from an operating system you are unlikely to be interested in removing the operating system from the stack, so that removes Microsoft, Red Hat, and Novell from the discussion

Actually since Microsoft owns both the CLR, and Hyper-V its position is slightly more complex.  It may be able to leave out the operating system and still maintain revenues from bundling the CLR and Hyper-V, and we will leave this discussion for a later article.  In this article we are mainly concerned about Java, and Java Virtual Machines, and the three obvious players left are Oracle, VMware and IBM.

JRockit VM (Oracle)

In fact, it turns out that Oracle is taking the lead in this area. It owns at least a couple of Application Servers (WebLogic and Oracle Application Server) and 3 hypervisors (VirtualBox, Solaris containers and Oracle VM – based on Xen), and three JVMs (Sun Hotspot and JRockit (from BEA), there is actually another one inside the Oracle Database), but it is JRockit that is driving the Operating System out of the stack.

JRockit was developed on a shoestring in Sweden by a 1998 startup.  It was acquired by BEA in 2002, then acquired by Oracle in 2008. It was never mainstream, but heavily promoted by Intel to encourage IBM and Sun to keep their x86 JVMs as performant as their Power and Sparc JVMs. In 2006 BEA started talking about a new version called LiquidVM that ran directly on the hypervisor, in those days specifically on ESX. It was only bundled with WebLogic Server, forming WebLogic Server – Virtual Edition.  Uptake was not significant and it appears to have faded away in the last 3 years.

However, with the acquisition of Sun by Oracle, and the emergence of a broader range of languages which directly target the JVM, its time may have come again and Oracle has re-launched the product as JRockit VE JVM, and this time there is no VMware support, the only hypervisor it supports is Xen, or more precisely Oracle VM. Again it only comes bundled only with an Application Server, namely Oracle WebLogic Suite Virtualization Option.

At a technical level, you may be wondering what exactly is going on. Oracle provides the above diagram showing how (through the magic of PowerPoint) the big thick purple box containing an operating system is shrunk to a thin red line containing a “Bare Metal Layer” not at all like an operating system.  The interesting thing here is that the JVM is an unmodified Linux JRockit JVM, so the “Bare Metal Layer” would appear to be not that different from the O/S it is replacing.

But before we are too cynical about this they do explain that there is no Linux or BSD or ” Normal Kernel” in the Bare Metal Layer, and in total it has a disk footprint of 2MB.  It contains only networking, thread scheduling, memory management and file storage.  It has a few Posix APIs, but is single user, can only run one application (the JRockit JVM) and one process at a time (there is threading to support the JVM threading model, but no processes). There are no real device drivers, it speaks directly to the LVM for disk access, and has an internal TCP/IP stack that goes out to the devices via the hypervisor.  They claim that (apart from page faults) the entire stack inside the virtual machine is in “User Mode” in other words the JVM and the drivers are all in the same memory address space and you don’t need to switch contexts into Kernel Mode in order to perform I/O or network access.

For the earlier Liquid JVM, BEA quoted a 33% speedup over a conventional virtualized stack, mainly based on increased speed of garbage collection.  The JVM is a peculiar user of memory in a traditional operating system because its heap space is pre-allocated, and may be paged in and out by the operating system. When garbage collection comes along the O/S has to page the memory back in.  However, in a traditional virtualized environment this is made more complex by the fact that the hypervisor actually does the paging, not the underlying O/S.  By removing the operating system there is no extra layer of complexity.

One area of concern has to be security. Everything inside the JVM is a single user, and so the notion of the user is only enforced by the JVM application layer, rather than by a traditional Operating System. In essence, they have moved the defenses to the container of the JVM with no defense in depth included as the defense in depth was often part of the traditional OS. With a THIN layer there seems to be some missing components.   Once you virtualize you do not magically become more secure, and this fact is missing from the JRockit JVM.

There is an ssh server that can be used for a limited form of management.  Generally management is at the JVMTI/PI in the JVM and JMX layer in the application server.

Oddly, the Bare Metal Layer can actually run on certain hardware platforms without a hypervisor. Another way of thinking about this is that it has always been feasible to run a JVM on a fairly thin “Bare Metal Layer” on raw hardware but it would be incredibly limited in the range of supported hardware simply because of the cost of writing drivers for all the possible devices.  However, since one of the side-effects of virtualization is to provide to the operating system a standard interface to underlying hardware, this problem has gone away.

Oracle’s strategy here is not about Virtualization per se.  it is much more about adding features to a self-contained stack. One of the peculiarities of this licensing model  is that you cannot take the underlying JRockit VE JVM and simply run your favorite Java application on it.  Moreover, since (unlike the GPL-licenced Hotspot JVM) JRockit  is a closed-source implementation, there is no obvious route for VMware  to take another application server (like VMware’s SpringSource DM or SpringSource TC), modify the Bare Metal Layer to run on ESXi and have their own Java stack running directly on the hypervisor.

Overall, the JRockit VE JVM project seems a little bit like a “skunkworks”.  It is supported product, but Oracle isn’t betting the farm on it, and indeed it’s not clear when the Oracle salesman will decide to sell this, rather than to include Oracle Enterprise Linux or Solaris in the mix. It does, however provide a reference point in the marketplace for a Virtualizable JVM without an underlying O/S.

VMware

The real question is, given we now know it can be done, does VMware have a strategic initiative (or even a skunkworks) to engineer a similar bundle for its SpringSource runtimes? It would have to pick up a JVM, and provide a thin O/S layer like the “Bare Metal layer” that sits underneath JRockit VE.  Alternatively it can continue to work with JeOS (Just Enough Operating System), where the Linux kernel is still present.

However, the recent announcement between VMware SpringSource and Google shows that VMware is heading into a different direction. That is the direction of allowing developers to develop anywhere, using well known development bundles such as Spring, and Google Web Toolkit (GWT). This allows code developed on Spring to run within the Google Cloud, VMware Cloud, and VMware vSphere, as well as other Clouds. This becomes a more interesting discussion of the use of the cloud. While VMware may be improving JeOS to speed things up, they are more about scaling out to allow those Spring apps to run just about anywhere.

IBM

It is also quite interesting to consider what IBM can do here.  It has WebSphere Application Server and it also owns Equinox, the EPL-licensed open source OSGi Runtime (which underlies SpringSource DM).  IBM also has a JVM and a hypervisor (although only for it’s Power chip).  However unlike its Oracle WebLogic Suite Virtualization Option, IBM’s corresponding product, WebSphere Hypervisor Edition, contains a full operating system for both Intel and Power stacks.

Conclusion

So we have Oracle on one hand working on a fast JVM directly on some virtualization host, most likely Virtualbox or Xen. We have VMware scaling out  Spring  to other clouds such as the recent Google announcement while working on improving and streamlining Spring. The real joker in the JVM discussion is really IBM, they have the potential to do more than we know they are doing? Will they come up with there own fast virtualized JVM, join with Oracle, VMware, Microsoft, or some other to push their stack. IBM is heavily involved with OSGi which underlies Spring but do they want to own more of the application stack?