See below. On Jan 29, 3:47 pm, Streets Of Boston <[email protected]> wrote: > I'm not sure about DalvikVM, but some compilers take advantage of > 'final'. > > E.g. > Final variables can be put in registers of the CPU without worrying > that they may change during execution (constantly moving variable- > values back and forth from memory to registers could be omitted for > 'final' vars). > > Or the compiler itself may do some better optimization of binary code > generation if it knows that a variable is 'final' and will never > change. > > ... > > On Jan 28, 4:53 am, Tim Russell <[email protected]> wrote: > > > > > I've seen a lot of use of final for local primitives. > > > Presumable to indicate to the compiler that the value shouldn't be changed. > > > However, what's the implication of this on Dalvik? > > > I believe final local variables are usually placed on the heap for extended > > lifetime (for use in inner classes), so is their a runtime overhead rather > > than using simple locals (which use Dalvik registers)? > > > Thanks, > > Tim
First, let's make sure we're talking about the same thing. "Variables" are declared in methods. They only exist during the execution of the method -- or during the lifetime of any internal methods defined anonymous in classes defined that method. "Fields" are declared in classes. Their lifetime is exactly that of the instance. (There is an invisible reference to that instance in any nested non-static classes, or executions of methods, or potentially, methods on classes defined within methods). "Scope" generally is used to refer to "lexical scope" -- that is, which part of the code you can reference a variable. "Lifetime" is used to refer to how long an object, or a variable's value exists. Generally speaking, variables will be on the stack, while fields will be within instances, which are always in the heap. Variables which are declared final, and which are referenced by methods of anonymous inner classes, MAY be copied to the heap as part of the implementation. That's hidden, and not important to you, unless you're counting the byte cost of an inner class instance. Actually, (assuming you're really talking about variables, and not fields, see below) compilers could do the optimization you describe, but I doubt it, because it would be lame. Here's why: The optimization you describe can be done for any variable which IS NOT assigned. A final variable CAN NOT be assigned. This is a subset of the above category. All Java compilers, as part of required error checking (including the check for "definite assignment") know specifically whether a variable is assigned. That is, they know the complete, larger set to which they can apply the optimization -- without the 'final' to act as a hint. So I doubt they actually fail to optimize unless you supply 'final'. It's not impossible though -- some compiler writer could have decided to use it as a user-hint as to what might be optimal. However, since users are unaware of it -- it's not part of the language, and users really don't know the tradeoffs -- they're complex and hard for even compilers do to well -- this would be more of a misfeature, resulting in a net slowdown over all the code. As to 'final' and inner methods -- I am baffled why that's still in the language. Guy Steele (the author of the Java Spec) very definitely knows how to remove that restriction. It's not in compilers he wrote for Lisp and Scheme. Actually, he knows more than one way. So I'm puzzled why we have to do all these weird workarounds the compiler could do for us. As to whether this is a documented feature of Java -- definitely. The situation with final fields is a bit different. For one thing, those can be accessed via reflection, so the compiler won't really know. There, 'final' can and does affect compilation, often including inlining. I think it only happens within the class in question -- other classes might change between when your code is compiled and when it runs. That could be handled by a clever classloader, but I'm not aware of it being done. But it's the sort of thing dex might do. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
