Hacker News Reader

Comment by justinsb | Hacker News Reader

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.

View on HN

> 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.

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.

Reply on news.ycombinator.com