20

I am curious to know what made google choose to develop android's framework on java VM.

In the process of writing code for android for nearly 6 months now, I observed that running code on a VM in a resource limited platform is really slow. There is a lot of overhead involved. I know that java is portable etc etc, is it not possible at all to use native languages and get both performance and features offered by a VM ? For performance oriented applications one still ends up writing native code and wrap it with JNI,

So why did google choose this particular stack :

  1. Arm based core (understandable, ARM is the best for mobile devices)
  2. Linux (Open source)
  3. Java VM (My question)

EDIT : I know java - JVM runs on par with C++ applications on my server, but not on android. With respect to android its not the case - As a matter of my experience, a C++ code wrapped with JNI runs far faster than java code (note I have even checked with exact same code from a static block in java) I will agree with your answer on any other platform.

EJoshuaS - Stand with Ukraine
  • 11,977
  • 56
  • 49
  • 78
srinathhs
  • 1,998
  • 4
  • 19
  • 33
  • @Woot4Moo that's not a very good response - it's a valid enough question to let the community decide if/how they want to answer, it's not that subjective at all – Daniel DiPaolo Dec 20 '10 at 16:43
  • 1
    It is not directly a programming question. It is based on speculation, unless we get someone from Google on here to answer directly for the architectural decisions that they made. – Colin Mackay Dec 20 '10 at 16:47
  • its subjective and argumentative to say the least Daniel. – Woot4Moo Dec 20 '10 at 16:52
  • By the way... Google didn't decide that. Google bought Android when it already had been developed. – Cristian Dec 20 '10 at 17:00
  • @Cristian: Just because they bought it from another entity does not mean they did not have control over it. Do you have more information about this? The question would be was it outsourced or was it intentionally separated? Perhaps Google wanted it to look like it was not their product until the last minute. Make a surprise out of it. – 700 Software Feb 26 '11 at 20:00
  • 1
    @Cristian: At the time that Google bought Android, Dalvik didn't exist and there were no firm decisions about the technology stack. – danfuzz Jan 27 '12 at 17:07

4 Answers4

5

The Dalvik VM uses its own bytecode, not Java bytecode. It's designed to be very fast (relatively speaking). I think the "VM" part of its title is a bit of a red herring, as people tend to assume that it will be "slow" no matter what. You said it yourself, you're working with a "resource-limited platform" -- that's likely your main cause of slow performance, much more so than the Dalvik VM.

Disclaimer: I am not an expert on Dalvik or Android in any way, shape, or form. However, it seems like people can tend to make a lot of assumptions about Android based on ideas like "it uses a VM" and "you write applications in Java", without looking into the platform further than that.

See this video for more information than you probably ever wanted to know on the Dalvik VM Internals (from Google I/O 2008).

Donut
  • 110,061
  • 20
  • 134
  • 146
  • yeah thats true, since at my official work we use java vm itself and I have no complaints on running a VM on my laptop or a power server, but is it really worth it running on a resource limited platform as android ? – srinathhs Dec 20 '10 at 16:46
  • @srinathhs It's not the same thing as the JVM. The Dalvik VM runs native bytecode. And I don't think I understand your concerns about it being a "resource-limited platform" -- mobile development is, almost by definition, resource-limited when compared to a "laptop or a power server" (which you seem to be doing, if I underdstand you correctly?). – Donut Dec 20 '10 at 16:59
  • exactly mobile development is resource limited, so why put a VM in there instead of anything else? (I am watching the google IO video right now) – srinathhs Dec 20 '10 at 17:12
  • Also [the slides](http://sites.google.com/site/io/dalvik-vm-internals/2008-05-29-Presentation-Of-Dalvik-VM-Internals.pdf?attredirects=0) to go with the video. – Josh Lee Dec 20 '10 at 17:16
  • @Donut - the dalvik VM does not run "native" bytecode (which would be arm or thumb opcodes), it runs dalvik bytecode. There are some architectural differences from a traditional JVM, but it's still the same idea of a program written for a different processor model than the actual hardware. – Chris Stratton Dec 20 '10 at 17:43
  • @Chris Stratton Noted; thank you. As I mentioned in my answer, I'm definitely learning as well. – Donut Dec 20 '10 at 17:55
2

1) Java is, as far as I know, the most universally taught language in universities and even high schools/equivalent. It is used widely in the professional world and has a lot of codebase behind it to help ease developers into creating more quality apps, faster.

2) The overhead is not that great vs. native code, especially with well designed code that is JIT optimized and being monitored by an ever-more-well-designed-gc.

Really, I think these two reasons alone can justify why Java was chosen as the primary language to be supported on Android.

Jon Willis
  • 6,993
  • 4
  • 43
  • 51
0

I think the key, is to not think about the Java VM in the same sense that you think of for Destkop or Server virtualization -- they're very different. At the most basic level, the Java VM (in this case Dalvik) is simply a translation layer between the bytecode generated by the "compiler" into native machine code. It is a virtual machine -- but it doesn't have the same overhead as say, running Ubuntu in VirtualBox.

Nate
  • 30,286
  • 23
  • 113
  • 184
  • 1
    Actually a dalvik VM has a lot more overhead than running x86 code in a VM hosted on an x86 box. Dalvik bytecode is not natively executable by the processor, and must be translated on the fly or via JIT. But the code running on a modern same-processor "VM" solution solution is allowed to run natively on the processor until a difference between the real and emulated environment forces the virtualization layer to temporarily jump back in. But on an android phone, only the upper level code is running in the VM - the operating system kernel and the low level drivers are native. – Chris Stratton Dec 20 '10 at 17:21
  • Thats true, what I meant by overhead, was that the "VM" doesn't have a window manager, device drivers, and many of the things that are typically part of a VM. – Nate Dec 20 '10 at 17:37
  • A more simple way to put it, might be to say there is less "OS" overhead running VirtualBox VMs than Dalvik VMs – Nate Dec 20 '10 at 17:41
  • actually there's more "OS" overhead running Ubuntu under VirtualBox. In the android case, the lower half of the OS is native to the hardware. But the virtualization is more costly, since it can't degenerate into "run this already native code until you hit a virtualization-related exception" – Chris Stratton Dec 20 '10 at 17:47
  • Good catch, I miss ordered the two items. I meant what you said ;) – Nate Dec 20 '10 at 19:11
0

Java applications have been proven(not always) to run just as quickly and smoothly as applications written in languages like c, c++, etc. See this reference, check out the PDFs. Many people say that java and the vm is slow without actually much proof or details - and this reference goes into some detail

Java is a widely known language and it's easy to pick up. putting the android sdk and tools in the hands of all these people who know Java already allows the android market to have a great potential of supplying its users with a large quantity of applications.

disclaimer: i'm no expert on this matter, just my 2 cents

james
  • 26,141
  • 19
  • 95
  • 113
  • 4
    With respect to android its not the case - As a matter of my experience, a C++ code wrapped with JNI runs far faster than java code (note I have even checked with exact same code from a static block in java) I will agree with your answer on any other platform. – srinathhs Dec 20 '10 at 17:04
  • 1
    A VM that is actually interpreting is going to be slower than native code. One that is ingeniously leveraging JIT might come closer - but by converting snippets of the program to run as native, rather than virtual code. – Chris Stratton Dec 20 '10 at 17:17