The source is here: https://android.googlesource.com/platform/art/+/kitkat-relea... and commit log: https://android.googlesource.com/platform/art/+log/kitkat-re... - So if somebody has the time to investigate it most questions should be able to be answered.
1) The compiler under compiler/dex seems to do a pretty simple set of optimizations and generate either code directly (compiler/dex/quick) or using LLVM through an intermediate code called GBC (compiler/dex/portable).
2) There's a new file format, OAT. Contrary to some reports, it doesn't appear to be a new bytecode, but rather a new file format for DEX bytecode. My guess it exists to support features like caching generated native code or compiling applications to images that don't have to be JIT-ed. The compiler has support for writing out ELF files, and LLVM can load ELF files dynamically with MCLinker.
3) There seems to be the start of a more sophisticated compiler under compiler/sea_ir. My guess is that it's intended to enable more high-level optimizations in the future. It seems to be a sea-of-nodes IR like the one used in Hotspot's C2 compiler, but doesn't seem to be either finished or plugged in. The change log suggests that it's still getting off the ground.
4) Judging by the commit logs, there seems to be a parallel-marking garbage collector, though otherwise it doesn't seem to be anything fancy.
Does anyone know whether Android/Dalvik has made decisions that lock them into non-moving/conservative GC or whether it's still a possibility in the future?
Doesn't answer your question, just some supporting evidence.
Is ART from the recent FlexyCore acquisition, or something else that has been going on for a while?
> FlexyCore doesn't seem to have done anything on the Internet for the last two years. The company actively promoted its product, releasing 11 videos in a one-year span, and then just stopped. The lack of recent activity makes it unclear if Flexycore has continued development outside the public eye.
We have already created that oat file above with
CreateOatFile. Originally this was just our own proprietary
file but now it is contained within an ELF dynamic object
(aka an .so file)
I found some random benchmark by a user on XDA (http://www.xda-developers.com/android/new-runtime-compiler-i...) that could indicate significant speedups with ART. Though I would take this information with a huge grain of salt right now as it is one benchmark from an unknown source.
That means Android can rely less on the fact that graphics and the guts of many UI widgets are native code under a thin layer of Java. Android was always a "Java OS" but it has become more so since Android 3. So ART is important to keeping Android quick.
Still, your mileage may vary. Unless you are doing significant computation in your app, a synthetic benchmark will vastly over-emphasize the impact of a better JIT.
Since this is still probably in alpha mode, I assume it could get even faster with further optimization.
It looks that it can compile to two banckends: one called "Quick" and other called "Portable"
I think "Quick" is a complete home backed Jit, while "Portable" is LLVM based
So probably (im guessing from fast source code study): This VM can JIT from bytecode to native while running (the Quick backend) and can run a already native payload using the LLVM backend..
The native payload probably will be very optimized since is AOT, and the Quick, since is JIT will probably have lower optimizations (as a runtime compiled code)
(and we can assume that, the Dalvik VM is getting obsolete)
Edit: adding more observations..
They have created a very sophisticated retargatable compiler that deliver into a SSA based IR and from there it goes to the backends that i have cited earlier
The bitcode from Pnacl is different from the LLVM one..
But the "portable" backend naming scheme maybe could mean they will use the PNacl-LLVM instead of the pure LLVM one..
I wonder how Chrome could glue with this.. but if the Nacl/Pnacl uses the PPAPI api, in this hypotethical scenario they would replace the PPAPI runtime with a runtime compatible with ART..
it can be done, and the final c++ application source code would look like the java one..
edit: This could also mean the ndk applications will be first class citizens and wont need to rely on a java shim + native bindings..
I think that is more likely than the ChromeOS integration scenario
and will have no JIT at all?
If they troubled creating their own IR and are not reusing the LLVM one.. it probably means that the LLVM backend are only being used to retarget to the several architectures supported by it..
Otherwise it doesnt make much sense, since they are controlling the optimizing compiler in a custom way without the LLVM help in that matter
Also, if we remember they use renderscript targeting the LLVM and, that the output could go directly to the graphic processors instead of the cpu, it make more sense to have this sort of design..
They work directly in the ABI and voila, everything just works and talk to each other despite its different roots (java, ndk, renderscript.. + ..put something else here..)
Potential improvements in the VM need to show they don't give up in other performance dimensions what they gain in JIT'ed code performance.
IMHO this will be absolutely compensated for by being able to switch into a low-power state earlier.
Dalvik's JIT is designed unlike other JITs: It is designed to JIT compile less code, but to find the code that has the highest impact. Dalvik's bytecode interpreter already gains what Google has claimed is a 2X improvement over interpreted Java bytecode. Before Android 2.3, that's how Android ran code.
On every single one of them, the brush ends up lagging ridiculously far behind my finger even with quite slow strokes, while on the FirefoxOS phone, I hardly noticed the lag unless I did fast sweeps or used a stylus (there is lag there but usually small enough that if using a finger, my fingertip obscures it)
Funny how Apple got the runtime right in 2007 and now, more than six years later, Google is still struggling with it.
Apple's clang/llvm transition was also already underway, but this had more to do with building more integrated developer tools and not having to deal with gcc, not as much the runtime.
ARC, perhaps the other big new thing you were thinking of, is again just a developer tool that was enabled by the transition to clang. Fundamentally, it is simply the compiler now being smart enough to inject retains/releases automatically when compiling your code instead of you doing it manually. Again, the impact of this is for developers, not end user (runtime) experience.
Microsoft dropped the JIT model from Windows Phone 7 and moved to fully native starting with Windows Phone 8.
 Ignore the pedants saying otherwise; it walks like a duck and quacks like a duck.
There is a JVM specification and Dalvik does not conform to it: that means it's not a JVM. It isn't pedantic to say that Dalvik isn't a JVM, because it's not. RoboVM isn't a JVM, either. Supporting Java does not a JVM make.
You were doing pretty good up to there. The Android toolchain does not compile to Dalvik bytecode. It translates from Java bytecode to Dalvik bytecode. So any language that compiles to Java bytecode could be used to write Android apps.
There are many projects to bring other JVM languages to Android.
And this is because Dalvik doesn't understand Java bytecode. It's not conformant to either J2SE or J2ME and these are examples of libraries that puke because of its nonconformance. That's all I'm saying.
Other things, like loading Java bytecode dynamically at runtime are limitations of not using Java(TM) bytecode.
I am not saying that Dalvik is bad. I'm saying it isn't a JVM; I was using this as just one example of its not-JVMness.
There's no "just" when it comes to the Codehaus implementation of the Groovy Language. According to the Codehaus Groovy project manager , "Groovy is not able to run properly on Google's Android mobile platform ... (It takes) 20 seconds to start up a simple Hello World".
BTW, that webpage was seeking students to do work making Groovy run on Android, but Google didn't accept that project, or any projects related to Groovy , perhaps because no students were interested or maybe because of Codehaus's history of mishandling GSoC projects. The last Groovy project ever accepted was one in 2011 rewriting Groovy's antiquated parser in Antlr 3.0. The project failed and Google only paid out half the project money.
Android-in-Go, with the middleware in Go, would be a different OS. Maybe a good one, but it would not be Android.
But I do think they should do it eventually, and move away completely from Java, because I think Java is a pain to learn, especially for new programmers who want to make Android apps. Being able to write Go apps for Android could make Android that much more attractive to developers.
In the meantime, this transition to ART apps, will be a huge benefit for users, as their apps will run better, especially on lower-end devices, which KitKat also addresses.