Java optimizations: (Hotspot/Dalvik) Optimization of final method returning a constant?

Question

Can anyone tell me if either Hotspot or Dalvik is smart enough to inline calls to a final method returning a constant (static final) int value? Ideally the method call would be replaced by the constant. This might either be at class load time or through JIT.

This has implications in the design of some code I'm working on.

Vernonvernor

Could you explain why such a transparent micro-optimization has an influence on your design? – Restless

java -XX:+PrintOptoAssembly can help you find out – Leonerd

I'm trying to share a single (contant) value with every subclass of a particular type, and so overloading a protected accessor method to do it, rather than providing it to the constructor to be stored in a field defined by the parent class. The additional overhead is significant to the usage. – Vernonvernor

Answer 1

I would think that the answer is "no, optimization will not happen because of absence or presence of the final keyword", at least on the HotSpot VM. But optimization will likely happen because of other factors.

Here's what Brian Goetz says in this article (sorry for the long quote):

Like many myths about Java performance, the erroneous belief that declaring classes or methods as final results in better performance is widely held but rarely examined. The argument goes that declaring a method or class as final means that the compiler can inline method calls more aggressively, because it knows that at run time this is definitely the version of the method that's going to be called. But this is simply not true. Just because class X is compiled against final class Y doesn't mean that the same version of class Y will be loaded at run time. So the compiler cannot inline such cross-class method calls safely, final or not. Only if a method is private can the compiler inline it freely, and in that case, the final keyword would be redundant.

On the other hand, the run-time environment and JIT compiler have more information about what classes are actually loaded, and can make much better optimization decisions than the compiler can. If the run-time environment knows that no classes are loaded that extend Y, then it can safely inline calls to methods of Y, regardless of whether Y is final (as long as it can invalidate such JIT-compiled code if a subclass of Y is later loaded). So the reality is that while final might be a useful hint to a dumb run-time optimizer that doesn't perform any global dependency analysis, its use doesn't actually enable very many compile-time optimizations, and is not needed by a smart JIT to perform run-time optimizations.

There's also a good post why final is not final any more, at least in Java 5.

Scapolite

The quote doesn't say the the JIT doesn't inline final methods. It says that it can inline methods even if they're not final, and that using the final keyword is not needed to get this optimization. – Restless

As i understand what you've quoted, The optimization will most probably happen. But the final is more or less useless. – Leonerd

Yes, I also understood that optimization will probably happen - but not because the absence or presence of the final field. Clarified the answer. – Scapolite

Answer 2

Inlining is something the JIT compiler might do if it detects a hot spot, a method in the byte code that has been called that often that it probably worth spending some CPU time on compiling the byte code into machine code.

There's a very good chance that the JIT compiler will inline a final method (as it can't be overwritten). And chances will be even better if that method just returns a constant value.

But it's my understanding - if the calling method is not a hot spot, then it will not be compiled and there'll be no inlining of the final methods.

(Information source in german language)

Vomiturition

Answer 3

Alternatively, Soot is expected to optimize Java bytecode for such case.

Meredithmeredithe