Google I/O 2008 - Dalvik Virtual Machine Internals
Google for Developers1 HN recommenders · 2012–2018
188K views · talk · dated · Uploaded 2008-06-03
Dan Bornstein's Google I/O 2008 talk on the internals of Dalvik, the virtual machine that runs Android code. It covers the motivation for its design, the dex format and its register-based interpreter, plus tips for writing code that suits the platform.
HN points to it as the primary source on Dalvik's dex bytecode, register-based design and memory-saving choices.
47:18The Tragedy of systemd
linux.conf.au
36:45Rich Harris - Rethinking reactivity
You Gotta Love Frontend
51:18Lexical Scanning in Go - Rob Pike
GoogleFOSSSydney
1:31:06William Byrd on "The Most Beautiful Program Ever Written" [PWL NYC]
PapersWeLove
1:48:55The Thirty Million Line Problem
Molly Rocket
1:03:51VCF East: Ken Thompson interviewed by Brian Kernighan
Vintage Computer Federation
1:04:04LISA11 - Fork Yeah! The Rise and Development of illumos
USENIX
1:19:52CppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17”
CppCon
4 comments from Hacker News
Here's Dan Bornstein's talk at Google I/O 2008 about the dex format and the original Dalvik interpreter: [VIDEO] I'm not sure how useful it is in comparing the Dalvik JIT to MonoTouch though.
I agree: within the Android ecosystem and even within the ARM family, bytecode provides portability: you don't have to compile and distribute apps for different versions of the ARM architecture. It's paradoxical however that to increase the portability of certain types of apps across mobile ecosystems, eg. iOS and Android, and now Ubuntu, your best bet can be to write the portable part in native C or C++, bypassing the Dalvik layer using JNI/NDK. This is apparently the common way to make cross-platform mobile games. On memory consumption: I haven't made any measurements, but the Android .dex bytecode format has been designed with low space requirements in mind. See [VIDEO] . However, all apps run in their own VM process, with lots of common structures shared with them using an initial shared VM process and clever forking. I always thought one of the main original motivations to use Java was because it's so well spread among developers. Since in the early days before the JIT compiler, there must have been a really obvious overhead even with the interpreter hand-coded in assembly. But they must have wanted to use a well known higher level language with good IDE support etc. Ubuntu mobile apparently uses Qt: "It uses QML to give you a really slick, easy development experience for native apps with engines in C or C++, and JavaScript for UI glue that isn’t performance critical. We also give you full native OpenGL, which the top games companies are using to make incredible games."
This is a great post. I like how they walked through all the steps and especially the "perf" tool. Ruby has a patch to do the same thing -- increase sharing by moving reference counts out of the object itself: Index here: [LINK] First post in a long series: [LINK] I think these patches or something similar may have made it into Ruby 2.0: [LINK] [LINK] The Dalvik VM (now replaced by ART) also did this to run on phones with 64 MiB of memory: [VIDEO] I think PHP might do it too. It feels like Python should be doing this as well.
There's an experimental branch for Ruby: [LINK] Dalvik also uses a register-based bytecode. The early versions of Android needed a more efficient interpreter. Dan Bornstein's talk: [VIDEO] A classic paper on Register vs Stack VMs: [LINK]