JamVM 1.4.3 =========== Welcome to the twentieth release of JamVM! JamVM is a new Java Virtual Machine which conforms to the JVM specification version 2 (blue book). In comparison to most other VM's (free and commercial) it is extremely small, with a stripped executable on PowerPC of only ~150K, and Intel 110K. However, unlike other small VMs (e.g. KVM) it is designed to support the full specification, and includes support for object finalisation, soft/weak/phantom references, the Java Native Interface (JNI) and the Reflection API. Supported Architectures ======================= JamVM currently only includes an interpreter (keeps it small). This means it is easy to port to new architectures as most of the code is written in C. So far, JamVM has been built and tested on : Linux ----- - PowerPC: my main platform, so this is the most tested. Built and tested on G3 and G4 systems. - i386: built and tested on i586, i686 (Pentium III), Pentium 4 Athlon. At least an i486 is needed because JamVM uses the cmpxchg instruction, which was first introduced on the i486. - ARM: ported and tested on the iPAQ running Linux (3950, with xscale PXA250 processor, though it should work on StrongARM). Little and Big Endian machines are supported, and soft/kernel FP emulation. - AMD64: built and tested on an AMD Athlon 64. It should also work on Pentium 4 supporting EM64T technology (but I haven't tested). Mac OS X/Darwin --------------- - PowerPC: built and tested on Mac OS X 10.3 (Panther) and 10.4 (Tiger) on G3, G4 and G5 systems. It should also work on 10.2, but you may need to install Fink. Note, gcc-3.3 gives better performance than gcc-4.0. - PowerPC64 (a.k.a G5): to build a 64-bit executable CFLAGS must include the flag -arch ppc64. If no option is given a 32-bit executable is built by default. - i386: JamVM has been built and tested on the MacBook Pro. BSD Variants ------------ OpenBSD : i386, powerpc, ARM, AMD64 (x86_64). FreeBSD : i386, powerpc, ARM, AMD64 (x86_64). KFreeBSD : i386 Class Libraries =============== JamVM is designed to use the GNU classpath Java class library (see http://www.gnu.org/software/classpath). A number of classes are reference classes which must be modified for a particular VM. These are provided and built along with JamVM (see INSTALL). JamVM 1.4.3 works with Classpath version 0.91 (the latest development snapshot). It should also work with the latest version direct from CVS (but check the Classpath mailing lists for possible patches). Later snapshots of Classpath may also work, if no modifications have been made to the VM interface. Note, JamVM 1.4.3 will not work with versions of Classpath earlier than 0.91, nor will it work with the class library from Sun or IBM's Virtual Machines. Building and Installing ======================= Please see the INSTALL file for full instructions. Running ======= You don't need to setup any environment variables to run JamVM. By default, JamVM installs in /usr/local/bin (see INSTALL for how to change it). Therefore, as long as you have /usr/local/bin in your path, you should be able to simply run `jamvm'. CLASSPATH, -classpath, -bootclasspath and LD_LIBRARY_PATH variables ------------------------------------------------------------------- The location of user classes can be specified on the JamVM command line using -classpath (or -cp) or via the CLASSPATH environment variable. If neither is specified, the classpath defaults to '.', i.e. the current directory. The -classpath option takes priority -- if this is specified, CLASSPATH is ignored. The system classes (GNU Classpath and JamVM's VM classes) are loaded via the system class loader. By default it searches the GNU Classpath installation directory and JamVM's installation location. This can be overridden using the -bootclasspath command line option, or the BOOTCLASSPATH variable. By default JamVM searches the GNU Classpath installation directory and the current directory ('.') for native libraries. Extra directories can be specified using the LD_LIBRARY_PATH environment variable. Testing ======= Currently JamVM has been used to run fairly major command-line programs including Javac, SPECJvm 98 benchmark suite, jBYTEmark and Mauve. It has also been successfully used with Jetty (a Java-based web server and servlet container) and Eclipse. FEEDBACK ======== I welcome feedback of any kind, e.g. bug reports, suggestions, etc. I'm always interested to hear how and if people are using JamVM so even if you don't have a problem drop me an email (email address at the bottom). JamVM "Features" ================ For those interested in the design of virtual machines, JamVM includes a number of optimisations to improve speed and reduce foot-print. A list, in no particular order, is given below. - Uses native threading (posix threads). Full thread implementation including Thread.interrupt() - Object references are direct pointers (i.e. no handles) - Supports class loaders - Efficient thin locks for fast locking in uncontended cases (the majority of locking) without using spin-locking - Two word object header to minimise heap overhead (lock word and class pointer) - Execution engine supports basic switched interpreter and threaded intepreter, to minimise dispatch overhead (requires gcc value labels) - Stop-the-world mark and sweep garbage collector - Thread suspension uses signals to reduce supend latency and improve performance (no suspension checks during normal execution) - Full object finalisation support within the garbage collector (with finaliser thread) - Full GC support for Soft, Weak and Phantom References. References are enqueued using a seperate thread (the reference handler) - Full GC support for class-unloading - Garbage collector can run synchronously or asynchronously within its own thread - String constants within class files are stored in hash table to minimise class data overhead (string constants shared between all classes) - Supports JNI and dynamic loading for use with standard libraries - Uses its own lightweight native interface for internal native methods without overhead of JNI - JamVM is written in C, with a small amount of platform dependent assembler, and is easily portable to other architectures. That's it! Robert Lougher <rob@lougher.org.uk> 21st May 2006.