... a thousand words (JamVM/OpenJDK update 2)

Firstly apologies to the people who commented on my first progress update (18th May). I'd hoped to do a blog update way before now, but I've had a lot less time to work on JamVM/OpenJDK port than I expected...

Xerces Ranby asked:

Does JamVM still produce those quick and fast startup times when using the OpenJDK class libraries compared to the fast startup times obtainable when using GNU Classpath classes?

[best of 3 runs]

rob@traken:~/JAM/tests$ time /usr/lib/jvm/jamvm-openjdk/jre/bin/java -showversion hello
java version "1.6.0_0"
OpenJDK Runtime Environment (IcedTea6 1.6.1) (6b16-1.6.1-3ubuntu1)
JamVM (build 1.5.5-openjdk, inline-threaded interpreter)

Hello World!

real 0m0.046s
user 0m0.030s
sys 0m0.000s

rob@traken:~/JAM/tests$ time jamvm -showversion hello
java version "1.5.0"
JamVM version 1.5.5-devel
Copyright (C) 2003-2010 Robert Lougher
...
Build information:
Execution Engine: inline-threaded interpreter
Compiled with: gcc 4.5.0 20100211 (experimental)
Boot Library Path: /usr/local/classpath/lib/classpath
Boot Class Path: /usr/local/jamvm/share/jamvm/classes.zip:/usr/local/classpath/share/classpath/glibj.zip

Hello World!

real 0m0.048s
user 0m0.030s
sys 0m0.020s

gnu_andrew asked:

Will JamVM still support GNU Classpath, as CACAO does?

Yes, most definitely. I still consider GNU Classpath as JamVM's main class-library as it's where my chief loyalty lies. On more practical grounds, even after the OpenJDK port is functionally complete it will still be a long time before it is as tested as JamVM/GNU Classpath. FWIW, many embedded systems seem to be quite happy with GNU Classpath. GNU Classpath is considerably smaller "out of the box" and much easier to build...

As far as development is concerned, I've taken a different approach to Cacao. Cacao implements the class-library differences within the VM-specific code using #ifdefs. While there's nothing wrong with that, I personally think it makes the code harder to read, and it's harder to get an overview of the changes.

Instead, I've tried to abstract the differences into a classlib interface. At times this has taken some thought and quite a lot of code re-arranging. If anything it's made the code cleaner, as a lot of the messier details are hidden (in general, I'm not a fan of information hiding, but removal of some of the VMFoo details makes the intent clearer).

Having said that, the classlib interface is mostly driven by the differences between GNU Classpath and OpenJDK as I find them. I'd like to think the interface is reasonably generic, but it will probably need changing if another class-library came along...

Currently the classlib interface has 40 functions, the gnuclasspath directory has 8 files, totalling 2552 LOC, and openjdk 10 files totalling 3491 LOC.

Christian Thalinger (hello, twisti!), linuxhippy (hello, Clemens!), Michael Starzinger (hello, Michi!), Stefan Ring:

Yeah, it's taken a long time, and lots of prevaricating. It's not been quite as boring and tedious as I expected; some of it I've actually enjoyed :) Debian might even re-instate JamVM (sticking pins in the Debian T-shirt I bought at FOSDEM, while looking for the Fedora 13 CDROM).

A picture is worth...