JamVM – A compact Java Virtual Machine | Hacker News Reader

JamVM – A compact Java Virtual Machine

jamvm.sourceforge.net

69 pointsscriptproof18 comments

For the lazy, the features list is quite impressive.

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.

    Execution engine supports many levels of optimisation from basic switched interpreter to inline-threaded interpreter with stack-caching (equivalent performance to a simple JIT).
    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)
    Stop-the-world garbage collector, with separate mark/sweep and mark/compact phases to minimise heap fragmentation
    Thread suspension uses signals to reduce suspend latency and improve performance (no suspension checks during normal execution)
    Full object finalisation support within the garbage collector (with finaliser thread)
    Full support for Soft/Weak/Phantom References (with Reference Handler thread)
    Full support for class and class-loader garbage-collection and unloading (including associated shared libraries)
    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
    VM support for invokedynamic (JSR 292)
    VM support for type annotations (JSR 308)
    VM support for lambda expressions (JSR 335)
    VM support for method parameter reflection
    JamVM is written in C, with a small amount of platform dependent assembler, and is easily portable to other architectures.

Useful, but how does it compare to Avian? As far as I can tell JamVM is not actually a JIT compiling VM at all, although the features list is optimistically phrased to make that a bit unclear. Avian is also very lightweight but it also manages to be a JIT compiler.

The lack of JIT is interesting to me; JIT does give higher performance, but at a memory cost (because JITted code is not shared between processes).

I think the 3 sweet-spots are:

* JIT (OpenJDK, Android Dalvik)

* AOT compilation (Android ART, RoboVM)

* Interpreted (JamVM)

I think JamVM is interesting, because there aren't many good options there. It's also presumably much simpler, so if you wanted to experiment (Golang-style lightweight threads is an interest of mine), it would probably be easier.

This is orthogonal, but the AOT versus JIT difference between ART and Dalvik is hugely overstated. Dalvik attempted to AOT compile, and when that wasn't possible it also maintains a pre-compiled cache for subsequent runs. Similarly, while ART attempts AOT, for various reasons it often resorts to JIT with some types of code. They both behave incredibly similarly.

ART is a ground-up rewrite of Dalvik. The AOT thing seemed to take root as some sort of differentiating talking point.

> The AOT thing seemed to take root as some sort of differentiating talking point.

I think it took root in part because even end-users who were only casually interested saw a dialog suggesting as much on upgrade. When you upgraded to an Android version that used ART, you got a message telling you that the apps were being precompiled, which took a while to finish.

There is currently no released version of Android that uses ART out of the box. It's available behind the development options in KitKat and as default in the L developer preview, but that's it. The "optimizing applications" screen comes after system upgrades also with Dalvik.

> because JITted code is not shared between processes

It depends on which JVM you talk about.

IBM J9 does it if I am not mistaken.

Additionally, the OS/400 JVM is integrated with the kernel JIT used for the bytecode executable format of OS/400 applications (TIMI)

http://www.drdobbs.com/new-to-the-as400/184404408

> I think the 3 sweet-spots are:

A few more to your list. These do all three.

- IBM Websphere RealTime J9

- Aonix Perc

- JamaicaVM

- Excelsior JET

Sometimes I find a bit sad that many equate JVM == OpenJDK, not understanding how many choices are out there.

Indeed, there's quite a few choices out there, especially for specialisms (large heaps, real-time applications etc).

Not only that, but it's also good to note that Android != Java. It's best described as Java-like, in that there are some libraries/features in Java that aren't supported in Android, so it's a bit of a misnomer to describe it as a full JVM.

Couldn't you say the same of J2ME?

True enough. I might have mis-stated things slightly.

I think the only difference might be the portability. Android takes 'Java' code and outputs 'android machine code' that can/does only runs on an 'android machine' (I think).

Compiled Java in theory should run the same on any JVM, as it's virtual machine code, and the 'machines' use the same set of defined instructions.

The same applies to other JVMs in the embedded space.

For example, J9, http://www-01.ibm.com/software/wireless/wece/features.html

==> jar2jxe: A utility for converting Java class and archive files to the native J9 JXE file format.

Or JamaicaVM Builder

https://www.aicas.com/cms/sites/default/files/jamaicavm_6.3_...

The big difference between these JVM and Dalvik, is that they are certified JVMs, whereas Google tried to workaround the licensing issue for embedded Java deployments.

One key difference is that avian runs on Windows, whereas JamVM does not appear to.

Used jamvm in some osgi products and it works well. however I never heard about Avian (http://oss.readytalk.com/avian/ https://github.com/ReadyTalk/avian) and it does look interesting.

a table of all JVMs: http://en.wikipedia.org/wiki/Comparison_of_Java_virtual_mach...

The PhD of Andreas Gal (now Mozilla CTO) dealt, among other things, with adding a JIT to JamVM called HotPath[0]. The code, unfortunately, is nowhere to be found.

[0] https://www.usenix.org/events/vee06/full_papers/p144-gal.pdf

The page indicates that JamVM can run on the PowerPC platform yet it requires GNU Classpath which doesn't work on PowerPC architectures... Does anyone use this on PowerPC? Unfortunately the only other alternative Kaffe seems to have been abandoned..

I like jam, but I tried to purchase a license for an embedded product, all I could get was a dial tone.

How does this compare with juanino

AFAIK, Janino is a compiler — it only replaces javac. Once you've compiled a class with Janino, it needs to be loaded into a JVM. JamVM is a whole Java Virtual Machine — it will actually run your program instead of the traditional Java implementation.

Reply on news.ycombinator.com