5 ms·
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
by justinsb 12y ago
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.
- personZ 12y agoThis 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.
- _delirium 12y ago> 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.
- crwll 12y agoThere 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.
- pjmlp 12y ago> 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 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.
- joncrocks 12y agoIndeed, 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.
- chc 12y agoCouldn't you say the same of J2ME?
- joncrocks 12y agoTrue 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.
- pjmlp 12y agoThe same applies to other JVMs in the embedded space. For example, J9, http://www-01.ibm.com/software/wireless/wece/features.html 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_manual.pdf 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.