Android—Why Dalvik?

Discussion in 'Java' started by Lawrence D'Oliveiro, May 29, 2011.

  1. 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.
     
    Lawrence D'Oliveiro, May 29, 2011
    #1
    1. Advertising

  2. Lawrence D'Oliveiro

    Roedy Green Guest

    Re: Android—Why Dalvik?

    On Sun, 29 May 2011 12:48:48 +1200, Lawrence D'Oliveiro
    <_zealand> wrote, quoted or indirectly quoted
    someone who said :

    >
    >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.
     
    Roedy Green, May 29, 2011
    #2
    1. Advertising

  3. In message <>, Roedy Green wrote:

    > 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.
     
    Lawrence D'Oliveiro, May 29, 2011
    #3
  4. On 5/28/2011 9:56 PM, Lawrence D'Oliveiro wrote:
    > In message<>, Roedy Green wrote:
    >
    >> 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.


    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
     
    Nasser M. Abbasi, May 29, 2011
    #4
  5. Lawrence D'Oliveiro

    Lew Guest

    Nasser M. Abbasi wrote:
    > 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.

    --
    Lew
    Honi soit qui mal y pense.
    http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
     
    Lew, May 29, 2011
    #5
  6. Lawrence D'Oliveiro

    BGB Guest

    Re: Android—Why Dalvik?

    On 5/28/2011 9:28 PM, Roedy Green wrote:
    > On Sun, 29 May 2011 12:48:48 +1200, Lawrence D'Oliveiro
    > <_zealand> wrote, quoted or indirectly quoted
    > someone who said :
    >
    >>
    >> 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.
    >


    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, May 29, 2011
    #6
  7. Lawrence D'Oliveiro

    BGB Guest

    On 5/29/2011 6:32 AM, Lew wrote:
    > Nasser M. Abbasi wrote:
    >> 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...
     
    BGB, May 29, 2011
    #7
  8. In message <irtsqa$9ae$>, BGB wrote:

    > ... 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, May 30, 2011
    #8
  9. In message <irtu02$bso$>, BGB wrote:

    > ... 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.
     
    Lawrence D'Oliveiro, May 30, 2011
    #9
  10. Lawrence D'Oliveiro

    BGB Guest

    On 5/29/2011 5:44 PM, Lawrence D'Oliveiro wrote:
    > In message<irtsqa$9ae$>, BGB wrote:
    >
    >> ... 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.
    >


    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.


    >> 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?
    >


    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, May 30, 2011
    #10
  11. Lawrence D'Oliveiro

    BGB Guest

    On 5/29/2011 5:45 PM, Lawrence D'Oliveiro wrote:
    > In message<irtu02$bso$>, BGB wrote:
    >
    >> ... there is always J2ME ...

    >
    > 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...


    >> 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.



    yep, probably fair enough...
     
    BGB, May 30, 2011
    #11
  12. Lawrence D'Oliveiro

    Roedy Green Guest

    Re: Android—Why Dalvik?

    On Sat, 28 May 2011 23:17:31 -0700, "Nasser M. Abbasi" <>
    wrote, quoted or indirectly quoted someone who said :

    >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.
     
    Roedy Green, May 30, 2011
    #12
  13. In message <>, Roedy Green wrote:

    > 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, May 30, 2011
    #13
  14. In message <irv0op$kde$>, BGB wrote:

    > On 5/29/2011 5:45 PM, Lawrence D'Oliveiro wrote:
    >
    >> In message<irtu02$bso$>, BGB wrote:
    >>
    >>> ... there is always J2ME ...

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

    >
    > 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â€.
     
    Lawrence D'Oliveiro, May 30, 2011
    #14
  15. Lawrence D'Oliveiro

    Lew Guest

    Lawrence D'Oliveiro wrote:
    > Roedy Green wrote:
    >> The big problem is the UI is quite different.


    > 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?

    --
    Lew
    Honi soit qui mal y pense.
    http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
     
    Lew, May 30, 2011
    #15
  16. In message <irv04d$jga$>, BGB wrote:

    > On 5/29/2011 5:44 PM, Lawrence D'Oliveiro wrote:
    >
    >> In message<irtsqa$9ae$>, BGB wrote:
    >>
    >>> ... 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.
    >>

    > 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.

    >>> 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?

    >
    > 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.
     
    Lawrence D'Oliveiro, May 30, 2011
    #16
  17. Lawrence D'Oliveiro

    BGB Guest

    On 5/29/2011 9:21 PM, Lawrence D'Oliveiro wrote:
    > In message<irv0op$kde$>, BGB wrote:
    >
    >> On 5/29/2011 5:45 PM, Lawrence D'Oliveiro wrote:
    >>
    >>> In message<irtu02$bso$>, BGB wrote:
    >>>
    >>>> ... there is always J2ME ...
    >>>
    >>> Which is unsuited to modern ultramobile devices, as pointed out earlier.

    >>
    >> 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â€.
    >


    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.
     
    BGB, May 30, 2011
    #17
  18. On 5/29/2011 10:26 PM, Lawrence D'Oliveiro wrote:

    >
    > 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
     
    Nasser M. Abbasi, May 30, 2011
    #18
  19. In message <irvfip$ufl$>, Nasser M. Abbasi wrote:

    > On 5/29/2011 10:26 PM, Lawrence D'Oliveiro wrote:
    >
    >> 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?


    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, May 30, 2011
    #19
  20. In message <irvak5$lnt$>, BGB wrote:

    > On 5/29/2011 9:21 PM, Lawrence D'Oliveiro wrote:
    >
    >> In message<irv0op$kde$>, BGB wrote:
    >>
    >>> On 5/29/2011 5:45 PM, Lawrence D'Oliveiro wrote:
    >>>
    >>>> In message<irtu02$bso$>, BGB wrote:
    >>>>
    >>>>> ... there is always J2ME ...
    >>>>
    >>>> Which is unsuited to modern ultramobile devices, as pointed out
    >>>> earlier.
    >>>
    >>> 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â€.
    >>

    > 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.
     
    Lawrence D'Oliveiro, May 30, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?VGltOjouLg==?=

    Why, why, why???

    =?Utf-8?B?VGltOjouLg==?=, Jan 27, 2005, in forum: ASP .Net
    Replies:
    6
    Views:
    580
    Juan T. Llibre
    Jan 27, 2005
  2. Horace Nunley

    why why why does function not work

    Horace Nunley, Sep 27, 2006, in forum: ASP .Net
    Replies:
    1
    Views:
    470
    =?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=
    Sep 27, 2006
  3. Mr. SweatyFinger

    VWD why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    1
    Views:
    387
    =?Utf-8?B?Q2lhcmFuIE8nJycnRG9ubmVsbA==?=
    Dec 21, 2006
  4. Mr. SweatyFinger

    why why why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    921
    Mark Rae
    Dec 21, 2006
  5. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,072
    Smokey Grindel
    Dec 2, 2006
Loading...

Share This Page