Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Google working on JIT compiler for Android (groups.google.com)
15 points by dminor on Nov 20, 2009 | hide | past | favorite | 10 comments


FMI: "Dalvik is the virtual machine which runs the Java platform on Android mobile devices"... but it's not a JVM: different file format and different instruction set. http://en.wikipedia.org/wiki/Dalvik_virtual_machine


Dalvik performance has nowhere to go but up. If there's anything good about Java is that its terseness allows for loads of optimizations.


> ... Java is that its terseness ...

Compared to what? Java has a reputation for many things, but terseness of syntax is not one of them.

I'm not trying to be derisive to the language, I just thought that was an odd assertion to make.


Elaborate syntax over an impoverished evaluation model and semantics. Java is inspired by p-code; you could implement a p-code interpreted with one switch statement in two pages.

A handful of primitive types + an straightforward single inheritence class based object system. The GC is run of the mill. Control semantics are none existent; try/catch is even more straightforward than C's longjmps.

The whole thing is small enough to be compiled for an early 90s set-top box running a 16-bit micro, and there is nothing wrong with that. In fact, it's beautiful.


Language syntax has nothing to do with optimization. Java is easy to optimize because the machine types of values in the program can be determined at compile-time. (Of course, with runtime information, you can pick even better machine types, which is what JIT is.)

The reason why languages like Perl and Python run so slowly is not because of the syntax, but because of the semantics. When one value can be a number on one line and a string on the next, it is difficult to convert that sequence to fast machine instructions.


Here's hoping that Cyan manages to pull something off with this in a future Cyanogen release. I can see a JIT running in a G1, and since we already are able to run Apps off of a class 6 SD card, I don't see any reason not to cache the compiled code.


Here we go then, a very much anticipated move.

If only they could've hacked freely on the real JVM itself they could have invested that huge amount of brainpower to improving something existing rather than merely first starting from scratch with their own VM.


This is awesome, but it also feels like something that should have been there from the beginning.


Maybe, but there's something to be said for releasing an imperfect version quickly and improving from there.


They very much believed that their optimized interpreter would be faster and better than JITing. And it is optimized -- they took into account cache locality, ARM instruction size, etc. You can read the design doc. They spent a lot of time on it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: