Porting JamVM to the CVMI

As part of working towards a common VM interface, the conversion of JamVM to a new OpenJDK/CVMI interface is being undertaken. This page lists the changes necessary to JamVM (in comparison with current CVS as of Wednesday, June 4th 2008). The repository was converted to Mercurial from CVS to aid the process of creating changesets and hosting the repository.

Why JamVM?

You may ask why we decided to use JamVM for this task. There are two main reasons:

JamVM currently supports only one class library, GNU Classpath, unlike other VMs such as CACAO and JikesRVM (see approaches to adopting the OpenJDK VM interface). This allows cases where the VM implicitly expects GNU Classpath to be more easily recognised and dealt with. The process is hoped then to also be similar to that required to port other GNU Classpath-only VMs such as GCJ.
JamVM is small and simple. The code base totals roughly twenty C files, and, being a C-based interpreter-only VM, the issues raised are likely to be more manageable and make a more easily understandable test case than porting, for example, GCJ, which is an Ahead-Of-Time (AOT) compiler and needs class library support for this. JamVM also uses an external class library, rather than relying on an integrated copy, which makes swapping Classpath for OpenJDK mainly a case of swapping glibj.zip for rt.jar and using OpenJDK's native libraries instead of GNU Classpath's.

Building the Port

Building the port involves using --with-java-runtime-library=openjdk to select the OpenJDK interface, and --with-java-runtime-library-prefix to point to an OpenJDK CVMI J2SDK image.

Patches

Below is a list of the patches we've applied to JamVM to support OpenJDK, and why. You can find copies of the patches by following the links on the titles or by using my patch repository.

Remove GNU Classpath specific code by commenting
This is a hacky patch which basically removes GNU Classpath-specific Java code, so that it can be compiled against OpenJDK. In the long run, this needs to be replaced.

	2008-08-04  Andrew John Hughes  <gnu_andrew@member.fsf.org>

	* lib/java/lang/VMClassLoader.java,
	* lib/java/lang/VMRuntime.java,
	* lib/java/lang/VMThread.java,
	* lib/java/security/VMAccessController.java:
	Remove GNU Classpath specific code through commenting.

API Update
This patch simply updates a call in VMAccessController that has become ambiguous due to a new constructor in CodeSource not yet present in GNU Classpath.

	2008-08-04  Andrew John Hughes  <gnu_andrew@member.fsf.org>

	* lib/java/security/VMAccessController.java:
	Remove ambiguity in call to java.security.CodeSource
	constructor introduced by recent API changes.

Add build support
This patch alters the build system so the class library can be specified. We rely on this with later patches to select the appropriate C code to use. Thanks to Christian Thalinger for the --with-java-runtime-library option which was adapted from CACAO.

	2008-08-04  Andrew John Hughes  <gnu_andrew@member.fsf.org>

	* configure.ac:
	Add --with-java-runtime-library from CACAO and
	change --with-classpath-install-dir to
	--with-java-runtime-library-install-dir.
	* lib/Makefile.am,
	* src/class.h,
	* src/dll.c:
	Define class library and native libs location
	depending on value of --with-java-runtime-library.

Handle differing StackTraceElement constructors
This patch supports the use of the public StackTraceElement constructor by OpenJDK. Classpath uses a package-private version which orders the arguments differently and directly takes the isNative setting. Now there is a public version (added in 1.5), Classpath VMs should probably use this. OpenJDK simply uses -2 as the line number to indicate a native method, and Classpath could do similar, thus removing the need for this patch.
```
	2008-08-04  Andrew John Hughes  <gnu_andrew@member.fsf.org>

	* configure.ac: Credit CACAO for
	--with-java-runtime-library macro.
	* src/excep.c,
	* src/symbol.h:
	Handle differing signature of StackTraceElement
	constructor.
	
```

Extend tracing support
This patch extends JamVM's trace support so we can obtain more valuable debugging information. This was useful in finding the issues solved by these patches.

	2008-08-04  Andrew John Hughes  <gnu_andrew@member.fsf.org>

	* .hgignore: Updated with autogen.sh output.
	* configure.ac: Add new trace options.
	* src/class.c,
	* src/excep.c,
	* src/natives.c,
	* src/resolve.c: Add trace support.
	* src/jam.h,
	* src/dll.c,
	* src/os/linux/os.c: Add support for reporting
	the linking error using dlerror.

Allow OpenJDK to store the protection domain
In GNU Classpath, the protection domain for a class is stored in java.lang.Class, while HotSpot maintains this value in OpenJDK. This patch simply lets JamVM store the value if using OpenJDK. In the long run, we should pick one approach over the other.

	2008-08-04  Andrew John Hughes  <gnu_andrew@member.fsf.org>

	* src/class.c,
	* src/jam.h:
	Change signature of defineClass to include
	protection domain.
	* src/jni.c: Fix call to defineClass to send
	NULL protection domain as HotSpot does.
	* src/natives.c: Send protection domain directly
	to defineClass on OpenJDK as there is no field to
	inject it into.

Load libjava.so for OpenJDK
Another OpenJDK-specific change. As we mentioned in the discussion of class library-->VM calls for OpenJDK, it is implictly assumed that libjava.so is loaded. Like CACAO, we do this during initialisation with this patch.
```
	2008-08-04  Andrew John Hughes  <gnu_andrew@member.fsf.org>

	* src/natives.c:
	Add support for OpenJDK loading of libjava.so.
	
```
Support NIO from JNI
As discussed in reference to VM to Java calls, the VM has to be able to create a DirectByteBuffer instance and link it to a native buffer. This patch adds OpenJDK support for this in JamVM. Again, long term, a common solution should be found.
```
	2008-08-04  Andrew John Hughes  <gnu_andrew@member.fsf.org>

	* src/jni.c,
	* src/symbol.h:
	Support creating a DirectByteBuffer from JNI
	under OpenJDK.
	
```

Document the VM differenes in natives.c
This is a simple patch to add missing documentation in natives.c.

	2008-08-04  Andrew John Hughes  <gnu_andrew@member.fsf.org>

	* src/natives.c:
	Document VM differences.

Handle initialising threads in OpenJDK
Again, our VM to Java calls discussion touches on the subject of initialising java.lang.Thread. This patch adds support for the OpenJDK method which differs from GNU Classpath by not having a java.lang.VMThread object (at present) and relying on the VM to create two java.lang.ThreadGroup instances called main and system, the latter being the parent of the former. Again, a long term goal is to amalgamate these two solutions.
```
	2008-08-04  Andrew John Hughes  <gnu_andrew@member.fsf.org>

	* src/symbol.h,
	* src/thread.c:
	Support initialising java.lang.Thread on
	OpenJDK.
	
```

Fix issues introduced moving to Mercurial
The following two patches fix some build issues that were introduced when we moved the local code base to Mercurial (the above series of patches).

	2008-08-04  Andrew John Hughes  <gnu_andrew@member.fsf.org>

	* configure.ac:
	Fix broken library location option.
	* lib/Makefile.am:
	Drop reflection classes for JamVM/OpenJDK.

	2008-08-04  Andrew John Hughes  <gnu_andrew@member.fsf.org>

	* src/symbol.h:
	Remove #ifdefs in #define.
	* src/thread.c:
	Add missing semicolon and move system_group
	definition up.