Does Android or Java use more power since it's running on a virtual machine?

Question

Since Android applications run on a JVM (Dalvik VM) which is basically a virtual processor, and every virtual instruction has to be mapped to the underlying chipset's native instruction, does this mapping result in more power consumption due to the overhead of this mapping?

This question can be extended to Java and also be phrased as "do Java applications use more power ?". Is this why Android phones have such appalling battery lives as compared to other platforms/phones ?

Edit: Based on the answers I've clarified a few points because I had erroneously spoken of JVM and Dalvik interchangeably. In this bit I'm talking about Java only to ask if it uses more power and if yes, does that conceptually apply to Android as well and does it result in decreased battery life.

Context: quoted from Wikipedia:

1. Java bytecode is analogous to assembly language for C code.
2. From the viewpoint of a compiler, the Java virtual machine is just another processor with an instruction set, Java bytecode, for which code can be generated.
3. JVM has a stack architecture. Dalvik is a process virtual machine which is not the same type of virtualization as JVM and has a register architecture.

Since Java programming language gets compiled to bytecode (assembly-like) and it runs on a virtual processor, it provides for true software code portability. Also, since there is a JVM for Linux and Linux has been ported onto open hardware, the combination can provide true application portability across the entire stack.

Power: The question essentially boils down to this - for the same set of functionality of your software code or application, what percentage of your CPU clock cycles are attributed to the run time environment. This is with the Just-In-Time compilation environment of modern JVMs where if the bytecode is compiled to the underlying chipset's native instruction, then the run-time should only be active during jit compilation. So how much more CPU clock cycles are used up in having the run-time environment which is expected to result in a power consumption overhead. I'm interested only in the power consumption aspect, and not the relative performance compared with statically typed and built languages and understand the advantages of Java. Sub-questions which might be related:

• Does the Java Run time use the libc for it's functionality?
• Do any of these power consumption related points translate to the Dalvik VM and Android?
• Instead of generalizing the poor battery consumption of Android without talking about the screen and wireless chipsets - lets talk about how the iPhone 5 has a 1440 mAH battery which is tiny compared to modern Nexus phones. This whole train of thought (Java, Virtual processor, instruction mapping, Android) arose because an iphone-loyalist friend claimed this could be the likely reason for his iphone having better battery life than my (awesome) nexus.

In any case, thanks for the answers below.

Answer 1

Your question is based on many flawed assumptions. Let me attempt to clear them up:

• You said "JVM (Dalvik VM)". That's like saying "Airplane (Bicycle)". These two things have absolutely nothing to do with one another.

• You said "...which is basically a virtual processor". Simply false. It is not the case that, every time the words "Virtual Machine" or acronym "VM" is used in a technical context, that it is essentially equivalent to VMware Workstation. This is because products like VMware do in fact emulate an entire computer, not only the CPU, and are running an operating system on top of another operating system. Dalvik VM does not work like that. Not even close.

• Java is just a programming language. It's syntax. Android/Dalvik programs happen to use the same or very similar syntax to a completely unrelated desktop/server programming language called Java, which runs on a Java Virtual Machine. In theory, you could write Java code that is very nearly the same speed as C code, since they are both high level programming languages. The devil's in the details of the implementation of the library calls and the way that the runtime is designed, which has very little to do with the syntax of the language.

• It is an over-generalization to say that Dalvik VM, the Sun Java Hotspot JVM, or the Java programming language syntax is responsible for high power consumption. The reason is that you have to compare whatever you're talking about to the performance of something else. In the most general case, when you're just comparing the "best-case" capabilities of both platforms, it is in principle possible to make Dalvik apps that are just as fast, or faster, than programs on any other platform. Other than automatic memory management and JIT compilation -- features which are standard in almost all programming environments these days, including on iOS and in JavaScript / HTML5 -- there is very little that separates Dalvik from Objective-C, .NET, Ruby, the Oracle Hotspot JVM, Python, and so on.

• The perception that "Java is slow" is due to a problem with old versions of Java, in that they either did not have a Just-In-Time Compiler (JIT), or the JIT they had was very limited in functionality. The JVM has had a Just-In Time Compiler for a very long time now. A JIT compiler is a part of the runtime (for instance, the JVM) that takes processor-independent bytecode -- for example Java bytecode -- and compiles it into native instructions for the CPU. This process is done when the Java program launches, and advanced JIT compilers can optimize individual functions or instructions at runtime to improve their performance based on observed results. For instance, if a method returns true every single time it's called, but it isn't obvious from the original bytecode that it would do so, the JIT compiler can recognize that it just returns true, and replace the function call with a hard-coded value of "true". This is just one example.

• JIT compilation and runtime dynamic code analysis techniques have been making huge advances in recent years. Many in the computer science community believe that, in another decade or two, the sophisticated analysis available in dynamically interpreted/compiled languages, such as Java, C# and Ruby, will be so advanced that, in most cases, these languages will execute faster at runtime than statically-compiled languages like C and C++. That's because static compilers are usually limited to compiling code at build-time, and the code is not modified at runtime. But in a runtime environment where the code of the program can re-write itself during execution to perform more efficiently, there is an enormous amount of upside that can be achieved by analyzing the performance of the code and making adjustments to reduce the complexity of the code or the number of instructions that are run on the CPU. For frequently-called code, the time investment required to perform the analysis is far outweighed by the performance benefits of repeatedly calling faster code.

• It should be noted that the Android Dalvik VM also contains a JIT, and that it does not use the same bytecode format as the Sun/Oracle JVM. Dalvik's JIT is optimized for low memory environments, and it is very advanced as far as runtime performance enhancements. So it is somewhat of a coincidence that the JVM and Dalvik implement similar optimizations for their respective Java-based runtime environment, but under the hood they are quite different.

• Don't forget that Dalvik itself; the Linux kernel; low-level system processes; and the core of Android web browsers (both Firefox and Chrome) are written in native C/C++, and so they do not have any of the overhead concerns that a Dalvik program would. This is the same as iOS. If you're talking about pure Android and not the carrier/third-party bloat that sits on top of it, a very large proportion of what comprises core Android is not written using Dalvik.

• Application developers on Android can also, at their option, write native code, bypassing Dalvik. If an application developer felt that Dalvik was acting as a bottleneck in the performance of their code, or causing it to drain too much battery, they could simply write C/C++ or even assembly code if they chose to, without having to obtain Google's approval to do so, and distribute their app like that.

Here are some actual reasons why an Android battery-powered device, or any device, may have problems with battery life:

• Applications that keep the CPU, screen, or data connection awake. In particular, 4G chipsets such as LTE use a great deal of energy when they are powered on, so if you have background programs that continually wake up the LTE chip to transfer a few kilobytes of data, that will drain your battery very fast. The screen on modern smartphones and tablets is also very energy-intensive, unless you turn the brightness down to minimal.

• "Bloatware" that is required to be on the device, and can't be uninstalled. Some unscrupulous carriers require you to run bloatware that takes up CPU cycles and keeps the data connection awake. This can be either due to incompetence on the part of the software developers of the bloatware, or an intentional goal of monitoring your activities on your smartphone and sending them to a remote server for data mining, which is very energy-intensive for your battery.

Finally, I disagree with your assessment that Android has worse battery life problems than on other mobile platforms. Certain phones and devices may indeed have battery life problems, either due to the capacity of the battery relative to the energy consumption of the hardware; poorly optimized power settings (elected by the user, the carrier, or the manufacturer); or bloatware apps that keep chips in the phone awake all the time. But for every example of a device that has battery problems, I can give you a counterexample of a device with excellent battery life. There's no simple way to generalize that "it's Dalvik" or "it's Linux" or "it's Java". Power optimization is a complicated hardware/software mish-mosh of competing concerns, including performance, responsiveness, and the user expectations for battery life, with pros and cons to each choice. To fully understand the power profile of a device, you have to take a close look at the battery itself, all of the hardware, and all of the software running on the device.

Answer 2

In this answer I will be comparing performance with Android and IOS as the two take up over 80% of the market share.

Java apps do not use more power. (http://www.javarants.com/2004/05/04/looks-like-apple-should-switch/) Oracle's Java VM or in reality Google's Dalvik VM is considered much more effient than IOS's Objective-C. Java is able to optimise code before it's executed on the phone which could result in much better performance. Java libraries are Open Source and therefore have been optimised by hundreds of different developers. On the other hand with IOS only Apple developers are able to change the code. Less review = less potential performance.

Android programs are also able to run native C code which could be disputed as faster than again Object-C (the only language supported on IOS).

The reason why Google decided on using the Dalvik VM is for portability. I know of four different CPU architectures that Android can official run on (ARM, MIPS, x86, I.MX). While every other phone OS can only use one (ARM). (http://en.wikipedia.org/wiki/Comparison_of_mobile_operating_systems) So comparing different CPU types with for example IPhone is unfair. If Android was ran on IPhone, Android would have comparable to superior performance and battery life.

"do Java applications use more power ?" Simply no.
Why Android phones have such appalling battery lives as compared to other platforms/phones ? Many Android phones are built cheaper than Apple's IPhone, but look at the price difference. The IPhone cost more because of the much larger battery with in it (and it's on average slower CPU). My android phone (Google Galaxy Nexus) has comparable battery life to the IPhone 4G but has much faster hardware specs (1GHz vs. 1.2GHZ).

EDIT: Java can optimise code without the programmer's knowledge required. Perfect, C code will always run faster than Java / Objective-C / C#; That said, how many programmers out there are perfect? At the JVM level Java and libraries will always be "more perfect" because of its open source development principles. (http://www.infoq.com/news/2012/03/Defects-Open-Source-Commercial)

EDIT 2: Small tidbit of information: Lenovo's new P780 Android Phone - 42 hours talk vs 12 hours on IPhone.

Answer 3

Yes, it does relate to increased power consumption - layers of abstraction will do that. It also leads to a decrease in speed (opposite side of the same coin - if something has greater overhead it will take longer to perform and thus use more CPU). If I understand correctly that is one of the advantages of what the NDK does - allow speedups for specific processors by writing specific code.

That said, for most jobs I'd imagine the "power related" overheads of running a VM are dwarfed by other considerations - for most programs the use of screen and radios will consume most of the power.

Answer 4

With regards to all other posters I believe what matters here most is not whether C/C++/Java exists but what the applications are doing.

Since power consumption maps directly with processing, I would ask myself what processing would a program do.

Say you're adding numbers. Say you're adding 2 with 2 on an infinite loop until you reach 2.000.000. Two questions arise:

1. How is it implemented: Is it a for-loop? Is it a while loop? (Is it a Goto/Label hack?)
2. How is the code being optimized.

These two questions ultimately define how many operations the processor needs to do and ultimately, how much power a device uses. This being said, the "overhead" of running a virtualized environment might be negligible due to the previous optimizing made by Java on the whole of the program, but then again, it all depends on what the application is doing.

Answer 5

Yes.

Virtual machines 'do everything twice', and not necessarily efficiently. So, they will use at least twice as much power to process the same instructions as a 'real machine'. The presence of a virtual machine slows things down and uses more power. Basically, OSes like iOS and WIndows will do everything faster and with less power consumption.

This translates to real differences in screen transitions, page loading, navigation, things like that. Currently Im comparing Android (VM) and Windows Phone, and even with a slower processor (1GHz vs 1.6GHz), Windows significantly outperforms Android doing the same kind of tasks.

However, what attracts the attention of most people is when they install an app and suddenly their battery gets used up more quickly. Thats not really due to the virtual machine, but an app that uses resources hungrily.

The whole reason for a virtual machine OS, portability, isnt a good reason to base an OS on. Do you see people buying phones with their favorite architecture and using Android because its portable? Do you see people giving up higher performance and reliability and putting android on their non-android phones? People buy an Android Phone, or a Windows Phone, or an IPhone, etc. To sacrifice performance for portability in low cost devices is impractical. It was a good idea that became a fail.