Do java finals help the compiler create more efficient bytecode? [duplicate]

Question

Possible Duplicate:
Does use of final keyword in Java improve the performance?

The final modifier has different consequences in java depending on what you apply it to. What I'm wondering is if additionally it might help the compiler create more efficient bytecode. I suppose the question goes deep into how the JVM work and might be JVM specific.

So, in your expertise, do any of the following help the compiler, or do you only use them for the normal java reasons?

• Final classes
• Final methods
• Final fields
• Final method arguments

Thanks!

EDIT: Thanks for all your answers! Please note that, as @Zohaib suggested, my question is a duplicate of this. I didn't search well enough before posting. I'm not deleting it because you guys made good contributions, but the answers could be merged. I'll let the "vote for close" system decide unless told otherwise.

Answer 1

The bytecodes are not significantly more or less efficient if you use final because Java bytecode compilers typically do little in the way optimization. The efficiency bonus (if any) will be in the native code produced by the JIT compiler.

In theory, using the final provides a hint to the JIT compiler that should help it optimize. In practice, recent HotSpot JIT compilers can do a better job by ignoring your hints. For instance, a modern JIT compiler typically performs a global analysis to find out if a given method call is a call to a leaf method in the context of the application's currently loaded classes. This analysis is more accurate than your final hints can be, and the runtime can even detect when a new class is loaded that invalidates the analysis ... and redo the analysis and native code generation for the affected code.

So best practice is to use final to (broadly speaking) express your design intentions, and to achieve other semantic effects that you require. (For instance using the final modifier can play an important role in implementing thread-safe immutable types; see JLS 17.5) If you use final as an optimization hint, you won't achieve much, and you will make your code harder to modify and extend.

UPDATE

There are a couple of exceptions to this (as pointed out below):

• Under certain circumstances, declaring a field as final changes the way that the bytecode compiler deals with it. I've given one example above. Another is the "constant variable" case (JLS 4.12.4) where a static final field's value will be inlined by the bytecode compiler both in the current classes, and in other classes, and this may affect the observed behaviour of code. (For example, referring to a constant variable will NOT trigger class initialization. Hence, the addition of a final may change the order of class initialization.)

• It is conceivable that declaring a field or local parameter as final may allow minor JIT compiler optimization that wouldn't otherwise be done. However, any field that can be declared as final could also be inferred to be effectively final by the JIT compiler. (It is just not clear that the JIT compiler actually does this, and whether that affects the generated native code.)

However, my previous advice applies. Use final to express your design intentions, not as an optimization hint.

Answer 2

That question has already been asked quite a lot and the answer generally is: the compiler might do some optimisations (e.g. inline constants which are final static fields) but generally you shouldn't bother with this, since those performance gains might actually not be noticable. Just use the final keyword for the "normal" Java reasons (make fields or parameters immutable, prevent subclassing or overriding of methods).

Answer 3

I suggest you test it with your code. It can make a different to the compiler in some cases however it is more likely to make a difference to the JIT. When it comes to micro-benchmarks and micro-tuning what should make a difference and what actually makes a difference is often not the same thing and only good testing is the way to be sure.

Another problem you have is that the JVM is improving all the time and a trick which made a big difference before may no longer apply. e.g. in Java 5.0 Lock was much faster than synchronized however in Java 6 the difference is much smaller and synchronized can be faster.

In generally, its a good idea to make your code simple, clear and easily maintainable and this will also result in efficient code.

Answer 4

Use of final gives none performance benefits at all. You have to resort to JNI for performance reasons. That said, it is advisable to use better JVMs that optimize the bytecode by themselves (eg: eclipse built-in runtime is more efficient than standard one) and lay more emphasis over your code.