Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail From: BGB Newsgroups: comp.lang.java.programmer Subject: Re: =?windows-1252?Q?Android=97Why_Dalvik=3F?= Date: Sun, 29 May 2011 09:35:37 -0700 Organization: albasani.net Lines: 103 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.albasani.net fw/doAs/njPga/tYC8KT9lmq/B+plMKQyWzcgaT0TeXADgddWfHqbfs45L0vW0mb6jkXd6be4Svmxxxn0O7ukQ== NNTP-Posting-Date: Sun, 29 May 2011 16:38:35 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="JseeYzPf4+hbwceKaIZqF/Ch3OIpPDhFV5djETKPMGa6/VEDzHX2z++Q2k+1oomL2xSYoBgLoJtvfnu0icpXr/jq+j6tJnq8/9XDQs0Fr+Hi8d8bgLKp5XMe0nP9YUdZ"; mail-complaints-to="abuse@albasani.net" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 In-Reply-To: Cancel-Lock: sha1:/saJAN2P9KBMQ3aJHaiykSmOOg8= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:4699 On 5/28/2011 9:28 PM, Roedy Green wrote: > On Sun, 29 May 2011 12:48:48 +1200, Lawrence D'Oliveiro > 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...