Using 'final' with local variables
in [Java Help]
|
Prev: inheriting a main method
Next: Adding int to a float
From: Arne Vajhøj on 20 Sep 2009 19:27 Dave Searles wrote: > Arne Vajh�j wrote: >> Dave Searles wrote: >>> markspace wrote: >>>> rossum wrote: >>>>> >>>>> I am talking about local variables, not member variables. >>>> >>>> I was just re-reading in Java Concurrency in Practice that some >>>> modifiers are important, because the JIT/javac will hoist variables >>>> out of loops: >>>> >>>> volatile boolean done = false; >>>> >>>> while(!done) >>>> processData(); >>>> >>>> "done" will be hoist out of the loop with out the volatile modifier, >>>> resulting in an infinite loop. >>> >>> Since that loop cannot set "done" the loop is infinite anyway >>> (barring an uncaught exception or System.exit() call beneath >>> processData() somewhere). >> >> Nothing is preventing processData from setting done to true. > > It's a local variable. It is not. Because volatile is not a valid keyword on local variables. It would not make any sense either. Arne
From: Dave Searles on 21 Sep 2009 06:46 Arne Vajh�j wrote: > Dave Searles wrote: >> Arne Vajh�j wrote: >>> Dave Searles wrote: >>>> Scott A. Hightower wrote: >>>>> rossum wrote: >>>>>> >>>>>> I am talking about local variables, not member variables. >>>>> I was just re-reading in Java Concurrency in Practice that some >>>>> modifiers are important, because the JIT/javac will hoist variables >>>>> out of loops: >>>>> >>>>> volatile boolean done = false; >>>>> >>>>> while(!done) >>>>> processData(); >>>> The discussion is clearly about local variables. >>> >>> It is clearly not >> >> Rossum explicitly said that it was. Are you calling Rossum a liar? > > No you are. No, I am not. > Rossum did not post about volatile. Scott did. In response to a post by Rossum that clearly established that the topic was local variables. > Rossum knows Java, so he will never claim that a volatile > variable is a local variable. Yet, apparently he did, or at least he implied it.
From: Dave Searles on 21 Sep 2009 06:46 Arne Vajh�j wrote: > Dave Searles wrote: >> Arne Vajh�j wrote: >>> Dave Searles wrote: >>>> markspace wrote: >>>>> rossum wrote: >>>>>> >>>>>> I am talking about local variables, not member variables. >>>>> >>>>> I was just re-reading in Java Concurrency in Practice that some >>>>> modifiers are important, because the JIT/javac will hoist variables >>>>> out of loops: >>>>> >>>>> volatile boolean done = false; >>>>> >>>>> while(!done) >>>>> processData(); >>>>> >>>>> "done" will be hoist out of the loop with out the volatile >>>>> modifier, resulting in an infinite loop. >>>> >>>> Since that loop cannot set "done" the loop is infinite anyway >>>> (barring an uncaught exception or System.exit() call beneath >>>> processData() somewhere). >>> >>> Nothing is preventing processData from setting done to true. >> >> It's a local variable. > > It is not. What part of >>>>>> I am talking about local variables, not member variables. do you not understand, Arne?
From: Jim Janney on 21 Sep 2009 19:45 rossum <rossum48(a)coldmail.com> writes: > A question for the Java gurus. When coding in C or C++ I use > 'register' to hint to the compiler that something might usefully be > kept in a place with easy/quick access: > > for (int i = 0; i < 20; ++i) { > register int iSquared = i * i; > for (int j = 0; j < 250; ++j) { > // Calculations involving i, iSquared and j > } > } > > That makes sense because the compiler is directly writing machine code > and can make use of the hint if it wants to. > > In Java there is no direct equivalent of 'register', the closest > probably is 'final' to indicate that the local variable will not > change. The approximate Java equivalent is: > > for (int i = 0; i < 20; ++i) { > final int iSquared = i * i; > for (int j = 0; j < 250; ++j) { > // Calculations involving i, iSquared and j > } > } > > However, in Java the compiler is creating byte code and the machine > code is created by the JIT from the bytecode so there is a less direct > connection between my source and the machine code. > > At last, my question: does the hint given by the 'final' keyword on a > local variable get through to the JIT or is it just wasted typing? > > Some days I add a 'final' to my unchanging local variables, other days > I can't be bothered. Which is the better practice? Is there likely > to be any impact on execution speed? > > I am talking about local variables, not member variables. > > Thanks, > > rossum In theory, I like to declare local variables as final whenever possible, because it enables a more nearly functional style of programming where each value is computed once and never changed. In practice I don't bother because it just seems to clutter up the code. As long as your methods are reasonably short there isn't a lot of local data flow analysis to do anyway. -- Jim Janney
From: Jim Janney on 21 Sep 2009 19:48
Thomas Pornin <pornin(a)bolet.org> writes: > According to rossum <rossum48(a)coldmail.com>: >> When coding in C or C++ I use 'register' to hint to the compiler that >> something might usefully be kept in a place with easy/quick access: > > It seems that modern C and C++ compilers tend to ignore such hints. > The net effect of "register" is now more something like: "punish me > if I use the '&' operator on that variable". This does have some practical value; the compiler can reasonably assume that a register variable is not aliased. FWIW, I think Datalight C was the first PC compiler to do global dataflow analysis and allocate registers based on that, but the big players, Borland and Microsoft, were quick to copy it. That would be somewhere around 1990. -- Jim Janney |