Performance tips for the Java final keyword

[RaviNada Kiran]

while going through Performance tips for the Java final keyword , i read that On the other hand, final methods can be inlined after being loaded into the JVM .What is meaning of this word ?? i can't understand the word inline with this context .

[Nitesh Kant]

It means that instead of having the code in a separate method, it will be put in place of the method call. This saves the creation of a new method stack. eg:

 

public void methodA() {
      methodB();
}

public final void methodB() {
     int a = 1;
     int b= a +1;
}

will be converted to:

 

public void methodA() {
     int a = 1;
     int b= a +1;
}

This is one of the many optimizations that a compiler does behind the scenes.

[RaviNada Kiran]

Thanks a lot Nitesh , you explained in a very simple manner .Earlier when i googled with inline final all sites are explaining about final constants, classes and methods .

One more doubt is that whether all this (inlining of final methods) will be done at compile time or at runtime ??

[Monu Tripathi]

RaviNada Kiran wrote:
One more doubt is that whether all this (inlining of final methods) will be done at compile time or at runtime ??

Read every word in the reply carefully Ravi....; words of wisdom cannot be overlooked!

Nitesh Kant wrote:This is one of the many optimizations that a compiler does behind the scenes.

[RaviNada Kiran]

Yes , you are right .( i am not a good listener and also realized that a bad reader also )


I didn't see the last line compiler

anyway thanks .

[Adam Michalik]

What's worth further explanation is that Java has two compilers: the 'javac' compiler that compiles the sources to the .class files (bytecode) and then the JVM compiler that compiles the .class bytecode to the native code when the application is started (on the fly). The said optimizations and inlining is made by the JVM compiler during runtime.

[Tim Holloway]

There are 2 good reasons to use the "final" specifier:

1. It provides an extra hint to the optimizer in case it's not smart enough to figure out usage from the context.

2. It provides safety to the programmer by flagging inadvertent modifications. Or, as the old saying went: "Constants - aren't, variables won't".

In older JVMs there were performance advantages to declaring a class final. They supposedly no longer apply, but some classes are final for other reasons. For example, Java.lang.String. It keeps people from getting too creative by subclassing core classes and overriding critical functionality.

[Gaurav Arora]

Tim Holloway wrote:
..
In older JVMs there were performance advantages to declaring a class final. They supposedly no longer apply, but some classes are final for other reasons.

I wonder if thats actually true. I'd appreciate it if you could present an article or something. I have read that very statement on a few different sites but have never found anyone who is able to cite his sources.

[Adam Michalik]

Have a look here:
Performance tips for the Java final keyword
Generally, with a Sun SDK and Sun Hotspot VM:
- the javac compiler does not inline anything (does not do what Nitesh Kant wrote), because, as explained in the above article:

suppose the compiler looks at class A and subclass B, and sub-subclass C and sees a final method in A which it inlines into C. But then at runtime the versions loaded for A and B are different and the method is not final in A, and overridden in B. Then C uses the incorrectly inlined version.

- the JVM may inline the calls to the final methods (as well as to other non-overridable methods, as private ones and these of final classes), but it is done on the native-compiled (machine code) level and one cannot be sure if it will be done (the JVM decides).
I remember reading a really good article about inlining somewhere on some Sun site, but I can't find it now... If I do, I'll post a link.

[Mike Simmons]

Adam Michalik wrote:the javac compiler does not inline anything (does not do what Nitesh Kant wrote)

Nitesh never said it was done by javac. He was simply explaining what inlining was. The original poster had already referred to it as something done by the JVM.

[Adam Michalik]

Hmm.. okay, I took it literally, but if we see it as an example/explanation then you (and Nitesh) are right

[Pat Farrell]

Tim Holloway wrote:In older JVMs there were performance advantages to declaring a class final. They supposedly no longer apply, but some classes are final for other reasons. For example, Java.lang.String. It keeps people from getting too creative by subclassing core classes and overriding critical functionality.

OT: I haven't checked recently, but java.lang.Integer was declared final, which meant you could not just subclass it to make a OID class. So I had to copy and paste all the source, to get all the usual functions, just to have a unique Integer-like object. What a pain, and a non-trivial performance hit, since it lost code reuse, increased working set size, etc.

[Monu Tripathi]

Gaurav Arora wrote:

Tim Holloway wrote:
..
In older JVMs there were performance advantages to declaring a class final. They supposedly no longer apply, but some classes are final for other reasons.

I wonder if thats actually true. I'd appreciate it if you could present an article or something. I have read that very statement on a few different sites but have never found anyone who is able to cite his sources.

I think this is worth pointing to, here.