Approaches to Implementing the OpenJDK VM Interface

This page lists the approach taken by VMs which have begun the arduous task of porting from the GNU Classpath VM interface to the OpenJDK VM interface. It is hoped that this can serve as an overview of the work undertaken by a diverse range of projects, with the end goal of aiding the process through the CVMI project.

CACAO

CACAO currently supports three different VM interfaces: GNU Classpath, Sun OpenJDK and J2ME CLDC 1.1. The code can mainly be found in src/native/vm but #ifdefs are also used at other points in the code, such as in src/threads/thread.cpp. These #ifdef statements separate code which differs from class library to class library. WITH_JAVA_RUNTIME_LIBRARY_GNU_CLASSPATH is used for GNU Classpath-specific code, WITH_JAVA_RUNTIME_LIBRARY_OPENJDK is used for Sun OpenJDK-specific code and WITH_JAVA_RUNTIME_LIBRARY_CLDC1_1 is used for J2ME CLDC 1.1. The corresponding #define is produced by configure using the --with-java-runtime-library option, which currently defaults to GNU Classpath, the more stable and long lived of the three.

Ideally, the CVMI project should work towards making it possible to erase most of, if not all, the differences between the OpenJDK and Classpath code, by either picking between the two solutions or creating an appropriate hybrid. Many differences, such as the creation of the initial thread groups (OpenJDK has two, system and main, while GNU Classpath just has main) are expected to be arbitrary and easily removable. Others will require more thought.

JNode

JNode is currently in the process of moving from GNU Classpath to OpenJDK, with its current codebase using a hybrid of the two class libraries. One problem JNode has with OpenJDK is the more extensive use of native code when compared to GNU Classpath. To make the VM interface of OpenJDK work for JNode, it has been necessary to provide VM support for redirecting certain methods on-the-fly. For example, a native call like hashCode in java.lang.Object is recognised by the VM and instead pointed to an internal VM Java method. The advantage of this is that the same technique can be applied to other native code that is not part of the VM interface. For example, JNode uses GNU Classpath's Java implementation of ZIP support, rather than the native OpenJDK support. Notably, the latter is not only native, but very specific to the native calls used by the zlib library (e.g. native long getEntry(long jzfile, String name, boolean addSlash in src/share/classes/java/util/zip/ZipFile.java, where jzfile is a native pointer).

One of the aims of the CVMI project is to make it easier for Java-based VMs to work with OpenJDK. To this end, we should look at ways to give such VMs more control, rather than them being forced to respond to specific native invocations.

JikesRVM

Support for OpenJDK is also currently being added to JikesRVM by Google Summer of Code student, Georgios Gousios, as part of integrating with JNode (above). This is still in the early stages. JikesRVM primarily supports GNU Classpath, but preliminary Apache Harmony support was recently added by Ian Rodgers.


Valid XHTML 1.1! Valid CSS!