7 ms·

So this is why we haven't seen much happening on the dalvik side. The source is here: https://android.googlesource.com/platform/art/+/kitkat-release https://an

So this is why we haven't seen much happening on the dalvik side. The source is here: https://android.googlesource.com/platform/art/+/kitkat-release https://android.googlesource.com/platform/art/+/kitkat-relea... and commit log: https://android.googlesource.com/platform/art/+log/kitkat-release 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.

randallu 13y ago
I thought Dalvik was quiet because the principal author (Dan Bornstein) left Google a while ago. Is ART from the recent FlexyCore acquisition, or something else that has been going on for a while?
- BitMastro 13y ago
  The commit history suggests that it started more than 2 years ago
  - yohui 13y ago
    While Google's acquisition of Flexycore was only made public recently, the process must have started years ago. As Ars Technica noted, http://arstechnica.com/gadgets/2013/10/google-buys-flexycore-creator-of-a-10x-speed-boost-app-for-android/ http://arstechnica.com/gadgets/2013/10/google-buys-flexycore... > 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.
- Ologn 13y ago
  One unfortunate thing about Bornstein leaving is he seemed to be the only one working on fixing the 65536 method limit bug/feature for Dalvik executables.
  - mateor 13y ago
    Tell me about it. All we get is simply spinning methods into separate jars every six months or so. Not a solution, IMO.
rayiner 13y ago
The guts are substantially different and seemingly more sophisticated. Notable things: 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.
- pcwalton 13y ago
  So I guess no moving GC still, because of LLVM. That's unfortunate. 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?
  - djh_ 13y ago
    Google made changes to how the JNI returns references to Java objects in Ice Cream Sandwich (4.0) so that native code can work with a moving GC. http://android-developers.blogspot.com/2011/11/jni-local-reference-changes-in-ics.html http://android-developers.blogspot.com/2011/11/jni-local-ref... Doesn't answer your question, just some supporting evidence.
  - dbaupp 13y ago
    Hopefully that means that Google throws some developers at giving LLVM better GC support, so the rest of us benefit.
- 13y ago
shreeshga 13y ago
Comment from the source[1]: 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) Seems like oat file might be enclosed in an ELF container and might support linking of shared libraries. [1]https://android.googlesource.com/platform/art/+/kitkat-release/dex2oat/dex2oat.cc https://android.googlesource.com/platform/art/+/kitkat-relea... [2]http://www.retrodev.com/android/dexformat.html http://www.retrodev.com/android/dexformat.html

randallu 13y ago

I thought Dalvik was quiet because the principal author (Dan Bornstein) left Google a while ago. Is ART from the recent FlexyCore acquisition, or something else that has been going on for a while?

BitMastro 13y ago
The commit history suggests that it started more than 2 years ago
- yohui 13y ago
  While Google's acquisition of Flexycore was only made public recently, the process must have started years ago. As Ars Technica noted, http://arstechnica.com/gadgets/2013/10/google-buys-flexycore-creator-of-a-10x-speed-boost-app-for-android/ http://arstechnica.com/gadgets/2013/10/google-buys-flexycore... > 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.
Ologn 13y ago
One unfortunate thing about Bornstein leaving is he seemed to be the only one working on fixing the 65536 method limit bug/feature for Dalvik executables.
- mateor 13y ago
  Tell me about it. All we get is simply spinning methods into separate jars every six months or so. Not a solution, IMO.

rayiner 13y ago

The guts are substantially different and seemingly more sophisticated. Notable things: 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.

pcwalton 13y ago
So I guess no moving GC still, because of LLVM. That's unfortunate. 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?
- djh_ 13y ago
  Google made changes to how the JNI returns references to Java objects in Ice Cream Sandwich (4.0) so that native code can work with a moving GC. http://android-developers.blogspot.com/2011/11/jni-local-reference-changes-in-ics.html http://android-developers.blogspot.com/2011/11/jni-local-ref... Doesn't answer your question, just some supporting evidence.
- dbaupp 13y ago
  Hopefully that means that Google throws some developers at giving LLVM better GC support, so the rest of us benefit.
13y ago

shreeshga 13y ago

Comment from the source[1]: 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) Seems like oat file might be enclosed in an ELF container and might support linking of shared libraries. [1]https://android.googlesource.com/platform/art/+/kitkat-release/dex2oat/dex2oat.cc https://android.googlesource.com/platform/art/+/kitkat-relea... [2]http://www.retrodev.com/android/dexformat.html http://www.retrodev.com/android/dexformat.html