Comparing Virtual Machine Interfaces
- 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
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.
The results of the OpenJDK Innovators' Challenge are to be announced on August 18th, 2008.
Keith Adams Dec 06, 2013