3 ms·
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 j
by rst 12y ago
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?
- Zigurd 12y agoI 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.
- daniel_solano 12y agoIt 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/ https://code.google.com/p/dexmaker/ 2. ASMDEX http://asm.ow2.org/asmdex-index.html 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.