4 ms·

> I'm not a big fan of the Dalvik virtual machine layer on Android. It provides a processor independent application format. It is obvious now that ARM has won

> I'm not a big fan of the Dalvik virtual machine layer on Android. It provides a processor independent application format. It is obvious now that ARM has won, but not so several years ago. There are many technical benefits to an abstract format including bytecode verification, and the consequent ability to run multiple applications in the same address space because you can't create pointers. JIT/hotspot style execution can also provide better performance than C. In any event providing a CPU neutral application format isn't a bad decision - others have done it too. > It does drain device resources, especially RAM. That claim needs to be substantiated. Is native code significantly denser than bytecode? The mobile vendors have all gone with GC. Mark and sweep style GC has more RAM in play by design than something like reference counting, but there is no requirement that mark/sweep is used - Dalvik could use reference counting. Again there are tradeoffs but calling them a drain seems a large stretch.

janardanyri 14y ago
> The mobile vendors have all gone with GC. It's a minor point, but Apple created ARC specifically as a streamlined reference counting alternative to GC, which was never used in iOS and is now deprecated in Mountain Lion.
- rogerbinns 14y ago
  I do count ARC as a form of GC. The test is if the developer has to manually litter their code with calls to release/free memory. You do not need to do so in Android (Java), iOS (ObjC), Windows Phone (C#) etc.
  - delackner 14y ago
    These terms have basic meanings that are independent of what you seem to wish they meant. GC is not reference counting, and it would benefit you to put he difference in your memory.
    - hetman 14y ago
      I've always seen "garbage collector" used as a generic term for an automatic memory management system, not a reference to the specific algorithm used to do it. It could be a tracing garbage collector or it could be using reference counting. Where are you getting the definitions that parent would benefit so from committing to his memory?
      - delackner 14y ago
        While some people might say reference counting is just a form of garbage collection, this blurs the useful distinction when discussing the overhead involved. Automatic memory management schemes that impose a variable runtime cost to analyze the object graph are simply totally unlike schemes that have no analysis step and thus no performance headaches. When people talk about GC being unacceptable for real time systems, they are not saying reference counting is unacceptable as well, they are simply saying that any system with a garbage collection phase are unacceptable. So that seems like a pretty clear split.
        taejo 14y ago
        Reference-counting schemes don't have the same performance headaches as GC's with an analysis step, they have different ones: * their own form of pause (when the last reference to a large tree of object disappears) -- this can rule out RC for real-time systems, while there are real-time GCs (though rare) * a non-local memory access per reference creation (whereas in other types of GC, the cost of allocation can be reduced to a single increment and compare of a value probably stored in a register) * none of the locality advantages of copying/compacting collectors
      - vidarh 14y ago
        Personally I tend to see it as down to whether or not the developer is involved (which dovetails nicely with your reference to automatic memory management). GC can be implemented via reference counting. But in my opinion, if the developer has to explicitly manage reference counting (e.g. by using "smart pointers" explicitly in C++) I tend to see it as distinct from GC.
  - pooriaazimi 14y ago
    You're right. But on iOS, we still have to think about it a little bit. Maybe not with malloc and free (or retain/release, actually), but in terms of object graph (we can't have "retain cycles", or "strong reference cycles", as they are called in ARC). It's a minor point and I agree with what you said, but I wanted it addressed in case someone who've not familiar with ARC gets the wrong impression :)
ttuominen 14y ago
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 http://www.youtube.com/watch?v=ptjedOZEXPM http://www.youtube.com/watch?v=ptjedOZEXPM . 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." It seems actually pretty nice for developers: http://developer.ubuntu.com/get-started/gomobile/ http://developer.ubuntu.com/get-started/gomobile/
qznc 14y ago
ARM is currently dominating, but Intel has not given up yet. A high-level representation is still a good idea in my opinion.
- fluidcruft 14y ago
  MIPS is still around on Android, too.

janardanyri 14y ago

> The mobile vendors have all gone with GC. It's a minor point, but Apple created ARC specifically as a streamlined reference counting alternative to GC, which was never used in iOS and is now deprecated in Mountain Lion.

rogerbinns 14y ago
I do count ARC as a form of GC. The test is if the developer has to manually litter their code with calls to release/free memory. You do not need to do so in Android (Java), iOS (ObjC), Windows Phone (C#) etc.
- delackner 14y ago
  These terms have basic meanings that are independent of what you seem to wish they meant. GC is not reference counting, and it would benefit you to put he difference in your memory.
  - hetman 14y ago
    I've always seen "garbage collector" used as a generic term for an automatic memory management system, not a reference to the specific algorithm used to do it. It could be a tracing garbage collector or it could be using reference counting. Where are you getting the definitions that parent would benefit so from committing to his memory?
    - delackner 14y ago
      While some people might say reference counting is just a form of garbage collection, this blurs the useful distinction when discussing the overhead involved. Automatic memory management schemes that impose a variable runtime cost to analyze the object graph are simply totally unlike schemes that have no analysis step and thus no performance headaches. When people talk about GC being unacceptable for real time systems, they are not saying reference counting is unacceptable as well, they are simply saying that any system with a garbage collection phase are unacceptable. So that seems like a pretty clear split.
      - taejo 14y ago
        Reference-counting schemes don't have the same performance headaches as GC's with an analysis step, they have different ones: * their own form of pause (when the last reference to a large tree of object disappears) -- this can rule out RC for real-time systems, while there are real-time GCs (though rare) * a non-local memory access per reference creation (whereas in other types of GC, the cost of allocation can be reduced to a single increment and compare of a value probably stored in a register) * none of the locality advantages of copying/compacting collectors
    - vidarh 14y ago
      Personally I tend to see it as down to whether or not the developer is involved (which dovetails nicely with your reference to automatic memory management). GC can be implemented via reference counting. But in my opinion, if the developer has to explicitly manage reference counting (e.g. by using "smart pointers" explicitly in C++) I tend to see it as distinct from GC.
- pooriaazimi 14y ago
  You're right. But on iOS, we still have to think about it a little bit. Maybe not with malloc and free (or retain/release, actually), but in terms of object graph (we can't have "retain cycles", or "strong reference cycles", as they are called in ARC). It's a minor point and I agree with what you said, but I wanted it addressed in case someone who've not familiar with ARC gets the wrong impression :)

ttuominen 14y ago

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 http://www.youtube.com/watch?v=ptjedOZEXPM http://www.youtube.com/watch?v=ptjedOZEXPM . 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." It seems actually pretty nice for developers: http://developer.ubuntu.com/get-started/gomobile/ http://developer.ubuntu.com/get-started/gomobile/

qznc 14y ago

ARM is currently dominating, but Intel has not given up yet. A high-level representation is still a good idea in my opinion.

fluidcruft 14y ago
MIPS is still around on Android, too.