Hacker News Reader

Comment by rcthompson | Hacker News Reader

It's kind of funny to hear AOT compilation being heralded as the next step after JIT that will bring better performance because you only have to compile once, since we spend so much time hearing exactly the opposite, especially in the context of Javascript.

(Notwithstanding that, as other comments have pointed out, JIT vs AOT is at best a gross oversimplification of the difference between Dalvik and ART.)

View on HN

Not really, it is deja vu for anyone that has been around in this industry for long time.

The idea of universal VMs go back to UNCOL project (1958).

A few mainframes made use of VMs with some kind of AOT compilation at installation time. The most notorious of it OS/400, still being used.

The first sucessful JIT compilers were designed as part of Smalltalk systems, namely SELF, which JavaScript is a descent of. So of course you hear a lot about it in the context of JavaScript.

Where JIT compilers bring a major win is when compiling dynamic languages.

With strong typed languages, the type of optimization algorithms you can make use of usually win over the limited options JIT compilers have available due to responsiveness limitations.

In the early 80s there was a fad of VM craziness around P-Code virtual machines, which eventually died out when everyone went back to proper compilers.

So this going back to AOT compilation trend, is just the IT circle going around one more time.

Apps and web pages are different use cases. An app you expect to spend a moment "installing" and are likely to use regularly, so AOT compiling is useful. Web pages on the other hand are often visited briefly and a few seconds delay can make a huge difference difference, and often contain lots of script executed only once or not at all - so AOT compilation would actually hurt performance.

Not really true with all the HTML5 apps based on Phonegap and WebView.

Not in the Android performance picture so far: language runtimes (e.g., jruby and groovy) that dynamically generate bytecode. A JIT can optimize it (and for jruby and grovvy on the jvm, it typically does).

That hasn't been an issue on Android so far because those language runtimes would have had to be retooled to generate Dalvik bytecode, and none of them were. (Ruboto, jruby on Android, runs in pure interpreted mode, with a significant performance hit.) But I believe that with Dalvik, it was technically possible. Does ART just close this possibility off?

I do not think dynamic DEX generation and loading was ever possible with Dalvik. So ART makes this no more or less difficult. An Android runtime environment, by definition, includes all the code to interpret DEX, even if it isn't made to be capable of using dynamically generated DEX.

But you have other problems to solve: How are you going to generate DEX? Generate java bytecode and bring dx to the runtime? Make jruby emit DEX directly?

EDIT: As per the comment below, that is how it's done. You generate Java bytecode and run dx on it.

It is entirely possible to dynamically generate and load DEX files in Dalvik, and it should be possible in ART.

To the best of my knowledge, there are too projects for generating Dex bytecode directly:

1. dexmaker https://code.google.com/p/dexmaker/ 2. ASMDEX http://asm.ow2.org/asmdex-index.html

A different approach, which I used for Clojure/Android, is to generate JVM bytecode and then use a bundled dx tool to generate Dalvik bytecode from that.

AOT + JIT is heralded more than AOT itself. This is because you can do both. Literally nothing stops you from doing both AOT and JIT'ing whatever you want (C/C++/Java/etc).

Reply on news.ycombinator.com