Android—Why Dalvik?

[Lawrence D'Oliveiro]

The Android Builders Summit
<http://free-electrons.com/blog/abs-2011-videos/> had some interesting
presentations, in particular Karim Yaghmour’s delving into the internals of
Android, and Aleksander Gargenta’s “A Walk Through The Android Stackâ€.

From 48:00 onwards, Gargenta explains why Android uses the Dalvik VM instead
of the Java VM.

* Why not Java SE? Too bloated, not suitable for low-power applications.
* Why not Java ME? Too expensive, everything runs in one VM => lousy
security. And you don’t get the necessary hardware access.

Dalvik is purpose-built from the ground up; its .dex code is, even
uncompressed, slightly smaller than a compressed .jar file. This simplifies
class loading—a .apk file can be opened and mmap’d, and the code is ready
for execution. (This is why zipalign is so important when building an
Android app.)

Dalvik is also register-based, not stack based, for higher performance.

 

[Roedy Green]

Dalvik is also register-based, not stack based, for higher performance.

I'll make some guesses.

Dalvik was designed solely for a family of CPUs with similar RAM.
Oracle Java wanted to run everywhere.

With Oracle Java, the licence forces users to provide the full
enchilada. I suspect with Dalvik they were able to prune it back just
to what they needed.

They are doing the old IBM lockin game. They don't want Android apps
running elsewhere or being easily ported there.
--
Roedy Green Canadian Mind Products
http://mindprod.com
How long did it take after the car was invented before owners understood
cars would not work unless you regularly changed the oil and the tires?
We have gone 33 years and still it is rare to uncover a user who
understands computers don't work without regular backups.

 

[Lawrence D'Oliveiro]

They are doing the old IBM lockin game. They don't want Android apps
running elsewhere or being easily ported there.

Android is already running on a bewildering variety of devices—e-book
readers, game console, media players, TVs, smartphones and tablets (of
course)—even a washing machine. There have been a number of devices that
dual-boot between Android and Windows; there is even a company looking at
implementing it as a stack running directly on top of Windows (good luck to
them).

There is no “lockin†anywhere. Android is being so wildly successful
precisely because it is so open and flexible. Google may not be keen on all
the things being done with it, but the beauty of it is it’s not their
decision.

 

[Nasser M. Abbasi]

Android is already running on a bewildering variety of devices—e-book
readers, game console, media players, TVs, smartphones and tablets (of
course)—even a washing machine. There have been a number of devices that
dual-boot between Android and Windows; there is even a company looking at
implementing it as a stack running directly on top of Windows (good luck to
them).

There is no “lockin†anywhere. Android is being so wildly successful
precisely because it is so open and flexible. Google may not be keen on all
the things being done with it, but the beauty of it is it’s not their
decision.

Hello;

I do not know anything about Andriod version of Java. But if one
writes an Andriod application, can one take the Java source code
and compile it with Java (the standard Java) and run it on say
window 7 or linux or the mac?

thanks
--Nasser

 

[Lew]

I do not know anything about Andriod [sic] version of Java. But if one
writes an Andriod [sic] application, can one take the Java source code
and compile it with Java (the standard Java) and run it on say
window 7 or linux [sic] or the mac [sic]?

Not unless one has the API ported to the other platforms. Even during
compilation Java requires that class references be satisfied, and of course
those libraries must be present to run the code.

Side note (that doesn't affect your question, really): there is more than one
"standard" Java. One assumes you mean Java SE, and further, a current version
thereof.

 

[BGB]

I'll make some guesses.

Dalvik was designed solely for a family of CPUs with similar RAM.
Oracle Java wanted to run everywhere.

well, it is possible, but register-based VMs are not necessarily
non-portable, just the performance argument is a bit weak, especially on
x86, since in both cases "register" and "stack" one generally ends up
having to map things to memory anyways.

likewise, many of my JITs will often map stack elements to registers in
many cases as well (when appropriate) so IMO the performance argument of
register VMs is a bit weak.

for a pure interpreter, it is a bit "who knows" and which is faster
ultimately comes down to a lot of micro-optimization and hand-waving.

my own experience has been that often the logic for dispatching to the
correct opcode itself becomes the main slowdown for an interpreter
(rather than messing with the stack), and that usually the way around
this is to have a number of "super opcodes" which include a sequence of
common smaller opcodes into themselves (such as combined
load+compare+jump opcodes, ...).


also, IME, register VMs are more of a pain to target than stack-machines
(and also often a little more complex). the result being that personally
I have usually ended up with stack machines.

With Oracle Java, the licence forces users to provide the full
enchilada. I suspect with Dalvik they were able to prune it back just
to what they needed.

partly, yes.

they do omit a few parts from a standard JVM... such as the
classloader... (AFAIK, the "Class" and "ClassLoader" classes are mostly
just stubs, ...).


although they still use the Java language, which could itself be a
factor in a legal sense (the alternative would have been to develop
"some language X" which "just happens to look mostly like Java and is
largely source-compatible").

They are doing the old IBM lockin game. They don't want Android apps
running elsewhere or being easily ported there.

possible...

however, given that Android apps are still (language level) mostly plain
Java, it is not so strong of an argument portability-wise.

it is much like how C is generally regarded as portable, despite the
fact that binaries will not generally work between one type of system
and another.


a much bigger problem then is likely any Android-specific library
dependencies, and Java's lack of a mechanism similar to C's "ifdef"...

yes... ifdef is kind of nasty, and is used/needed a bit more than is
ideal, but is a decent part of C-style portability (rather than asking
for a more-or-less homogeneous environment).

then any classes/methods/... related to specific GUI APIs and similar
would appear and disappear as needed.



oh well, if it matters:
I have long since given up my attempts to "bastardize" the Java/JVM
architecture with more features in my own implementation, and have
instead opted mostly with using my own language/VM for a lot of this
(this itself is gets a bit hairy in the details).

after all, if I pile on piles of new features/... then it is not really
the same language anymore anyways, even if the core syntax/... was
mostly similar.

but, yes, it is partly sort of a "who cares" situation regarding my
case. yet another HLL will not effect much in the greater scheme of
things, probably the best it can really do is to serve my own uses, and
even then it is a bit trying with all the time that goes into debugging
and working on it, rather than it "just working".

also, my current language is technically a bit more closely related to
ActionScript than it is to Java...


or such...

 

[BGB]

I do not know anything about Andriod [sic] version of Java. But if one
writes an Andriod [sic] application, can one take the Java source code
and compile it with Java (the standard Java) and run it on say
window 7 or linux [sic] or the mac [sic]?

Not unless one has the API ported to the other platforms. Even during
compilation Java requires that class references be satisfied, and of
course those libraries must be present to run the code.

Side note (that doesn't affect your question, really): there is more
than one "standard" Java. One assumes you mean Java SE, and further, a
current version thereof.

yep, there is always J2ME, and then one can define anything beyond this
as "extensions"...

granted, a "Java" which is basically just J2ME with everything else done
via proprietary APIs wouldn't likely appeal to most expecting Java SE
style functionality, even keeping the trademark intact.


"well, it has the Java 1.1 core language, and the packages java.lang and
parts of java.io and java.util..."

potential developer: "but what about AWT and Swing and these other APIs
I might want to use?"
response: "well, for these things you use our vastly improved
foo.gui.manager (it has Pointy/Clicky TM) and other custom APIs...".

at this point it would likely start to look a bit like someone trying
simply to use the Java trademark as a selling point.


or such...

 

[Lawrence D'Oliveiro]

... register-based VMs are not necessarily non-portable, just the
performance argument is a bit weak, especially on x86 ...

Which, interestingly, is not very popular for ultramobile devices.

although they still use the Java language, which could itself be a
factor in a legal sense ...

How come? Is the licence for the Sunacle JDK (which is what I use for
compiling programs) violated in any way?

 

[Lawrence D'Oliveiro]

... there is always J2ME ...

Which is unsuited to modern ultramobile devices, as pointed out earlier.

potential developer: "but what about AWT and Swing and these other APIs
I might want to use?"
response: "well, for these things you use our vastly improved
foo.gui.manager (it has Pointy/Clicky TM) and other custom APIs...".

at this point it would likely start to look a bit like someone trying
simply to use the Java trademark as a selling point.

Which Google has been careful to avoid.

 

[BGB]

Which, interestingly, is not very popular for ultramobile devices.

possibly, but I primarily develop on x86 systems, which have a few
relevant properties:
indirect addressing is nearly free;
memory in-cache performs nearly as fast as registers;
in 32 bit mode, there are only 8 usable GPRs, of which 2 or 3 are
generally needed by the CPU or ABI (ESP, EBP, and generally EBX on ELF
based targets).

now, maybe for RISC style targets things are faster, either with more
GPRs or slower memory access being a more major factor, but alas, I
haven't really used them much.

How come? Is the licence for the Sunacle JDK (which is what I use for
compiling programs) violated in any way?

apparently, Sun/Oracle is fairly fussy about who uses their trademark
and when, and basically they went and sued Google, IIRC (?), for using
their trademark in an unliscensed and partial implementation, and for
infringing on their patents.

although, normally one could just make a nearly identical clone language
with a different name, an issue is that pretty much all the standard JDK
packages use the word 'java' as part of their name, meaning that to
completely escape the trademark issue, one would also have to rename the
packages, breaking compatibility.


this is also partly why the standards documents for JavaScript uses the
name ECMAScript instead, and many alternative implementations and
variants of the language (JScript, ActionScript, HaXe, ...) also have
different names.

my own BGBScript language itself is (loosely) a JavaScript variant.
although it started out as a more loosely related language, was later
brought much closer to JS, and more recently drifted a lot closer to
ActionScript and added a few more non-JS features (the most drastic
re-addition being optional C/Java/... style declarations, as opposed to
using the 'var' and 'function' keywords...).

side-note: my big effort to make a big/new/fancy Java-like language
(with lots more features, like structs and properties, ...) ended in me
mothballing it (due to having bigger concerns) and just shoving some of
its planned features (and syntax/semantics) onto my existing script
language and VM, creating a sort of hybrid...


all this is in contrast to the more cohesive identity, say, of C, where
there is a more solid core language, and generally lots of
implementations and implementation-specific extensions. or languages
like Scheme where although a common name and identity are used, general
compatibility between implementations is nearly non-existent...


or such...

 

[BGB]

Which is unsuited to modern ultramobile devices, as pointed out earlier.

well, it can be used as a starting point, as generally people implement
the core VM and libraries, and anything after this is presumably
whatever they want to put in there...

so, it is basically like J2SE but without the requirement to implement
piles of classes which may / may not be applicable to the target.


but, if one just uses J2ME by itself, or is trying to write portable
apps targeting it, it is not so nice, as it doesn't ensure all the usual
standard features...

much like if one were trying to target a system which only had the C89
standard library and maybe a few OS-specific libraries and nothing else...

Which Google has been careful to avoid.

yep, probably fair enough...

 

[Roedy Green]

I do not know anything about Andriod version of Java. But if one
writes an Andriod application, can one take the Java source code
and compile it with Java (the standard Java) and run it on say
window 7 or linux or the mac?

The big problem is the UI is quite different. Android does not
support anything that looks like AWT or Swing.
I would imagine somebody eventually ports the Android UI to standard
java so you can run Android apps there. Going the other way would be
difficult since there is only 1 GB of RAM to play with.
--
Roedy Green Canadian Mind Products
http://mindprod.com
How long did it take after the car was invented before owners understood
cars would not work unless you regularly changed the oil and the tires?
We have gone 33 years and still it is rare to uncover a user who
understands computers don't work without regular backups.

 

[Lawrence D'Oliveiro]

The big problem is the UI is quite different.

There being reasons for that.

I would imagine somebody eventually ports the Android UI to standard
java so you can run Android apps there.

And what would that achieve? What platform would ship with this “standard
Java�

 

[Lawrence D'Oliveiro]

well, it can be used as a starting point ...

I don’t think Oracle’s licence allows you to use its code as a “starting
pointâ€.

 

[Lew]

There being reasons for that.

What are they, Lawrence? Do you know?

I would imagine somebody eventually ports the Android UI to standard
java [sic] so you can run Android apps there.

And what would that achieve? What platform would ship with this “standard
Java�

Any platform that ships with standard Java. I think Linux would be a likely
candidate, as it's what Darvik runs on already.

Google already has put out such a port. I've been running Darvik or something
much like it to which the Android libraries have already been ported, by
Google or someone with Google's cooperation, on my desktop Ubuntu box for some
time now. I downloaded it from Google.

Does that answer your question - - - - - Lawrence?

 

[Lawrence D'Oliveiro]

now, maybe for RISC style targets things are faster ...

The issue is power consumption. Intel has been unable to drive down the
power usage of x86 chips to offer serious competition to ARM.

apparently, Sun/Oracle is fairly fussy about who uses their trademark
and when, and basically they went and sued Google, IIRC (?), for using
their trademark in an unliscensed and partial implementation ...

I don’t recall any trademarks being at issue in that suit.

... and for infringing on their patents.

Which is a separate issue.

 

[BGB]

I don’t think Oracle’s licence allows you to use its code as a “starting
pointâ€.

no, not using code, but using its spec, and writing something according
to the spec...


for example, one can write their own version of the JVM, with their own
class libraries, and their own version of the compiler, ...

whether or not this is more or less effort than designing a language and
VM clean is a matter of debate though, as there are merits and drawbacks
either way.

 

[Nasser M. Abbasi]

The issue is power consumption. Intel has been unable to drive down the
power usage of x86 chips to offer serious competition to ARM.

Do you think the new intel 3D chips would do that?

http://www.mobiledia.com/news/89236.html

"Santa Clara, Calif.-based company said its "Tri-Gate" technology
turns microchip channels -- traditionally flat -- on their side,
creating a high, slender connector for higher performance
and lower power consumption, which is particularly important
for small mobile devices like smartphones and tablets. "

http://www.computerworld.com/s/article/9216451/Intel_s_3D_transistor_fuels_tablet_fight_with_ARM

"On Wednesday, Intel announced that it has made a major
leap in advancing chip technology: 3D transistors. The new
technology, expected to make PCs, smartphones and tablets
faster and more power-efficient, is slated to make its first
appearance when Intel moves to 22-nanometer chips next year."

etc//

--Nasser

 

[Lawrence D'Oliveiro]

Do you think the new intel 3D chips would do that?

Not a chance. They’ve already tacitly given up on phones for now, but are
still making a big noise about tablets. Though I’ve yet to hear of any
significant design wins.

The only advantage to having x86 on a tablet is the ability to run Windows.
And nobody seems to care about that.

 

[Lawrence D'Oliveiro]

no, not using code, but using its spec, and writing something according
to the spec...

But the J2ME spec is unsuited to ultramobile devices, as pointed out
earlier.