Comparing Virtual Machine Interfaces

Andrew John Hughes has been comparing OpenJDK to GNU Classpath in his recent blog entries. Hughes has been working on building a virtual machine interface for OpenJDK that will allow it to be quickly ported to various VM implementations. This work has been part of the OpenJDK Innovators' Challenge, in which Hughes is one of the eight finalists; the final proposal from Hughes was posted earlier this year. The other proposals include:

• Java Closures - Neal Gafter
• XRender Pipeline for Java2D - Clemens Eisserer
• JSR-310 Date/Time Library - Stephen Colebourne, Michael Nascimento Santos
• Portable GUI Backends - Roman Kennke, Mario Torre
• Free Software Synthezier Replacement - Karl Helgason
• OpenJDK Build Process on Windows - Ted Neward

While developing the solution for virtual machine interfaces, Andrew has been documenting the different different approaches taken between OpenJDK and GNU Classpath.

GNU classpath has been designed for several years for VM portability, with several examples of GNU classpath-enabled VMs (JamVM, CACAO, and Kaffe among others). OpenJDK, on the other hand, was built around one JVM, Hotspot, over the course of the past several years. As indicated by Hughes, the boundaries of the virtual machine and the class libraries exist, but the line may be a little less clear simply due to this evolution:

Both solutions do provide separation between the library and the VM. Contrary to what may be initially assumed, this is true of OpenJDK even though both HotSpot and the JDK are maintained in the same location. This is what allows different versions of HotSpot to be swapped in, as mentioned in the OpenJDK trademark license. That said, there are likely to be closer ties between the JDK within OpenJDK and HotSpot than there are between GNU Classpath and any of its VMs, simply because of the number of and variance between the latter.

Here are some of the differences that Andrew has found:

• Preloaded Native Library - libjava.so is a custom Java library that must be pre-loaded for OpenJDK, as opposed to being loaded by the class libraries as needed. Hughes explains how CACAO (an open-source JVM that already supports OpenJDK) handles this:

In CACAO, a special OpenJDK case is provided in src/native/vm/nativevm.c to handle this. This needs to happen early in the VM initialisation process before any of the native calls in the core classes are used.

• VM delegate classes - Many of the core libraries in OpenJDK delegate directly to a native interface (Andrew uses Object.wait, a natively declared method as an example). In contrast, GNU Classpath introduces an intermediate VM* class in most cases, which for Object.java is VMObject.java - this class performs all native delegation, and replaceable by the underlying JVM implementation.
• Class Library Invocations from VM Code - There are certain cases in both VMs where calls must be made into the class library from the VM. Because of that, the internal structure of the class-library has a very direct influence on the VM implementation. Cases mentioned by Hughes where there are differences include booting the JVM, creating NIO byte buffers, and dealing with threads and thread groups.

While the source for the Sun JDK has been available under various licenses for quite some time, GNU Classpath, for legal reasons, has evolved without any exposure; none of the Sun JDK licenses have been open-source compliant. Since the Sun JVM and JDK has been re-licensed as GPL, however, developers are starting to compare and contrast the two platforms.

The results of the OpenJDK Innovators' Challenge are to be announced on August 18th, 2008.