aspose file tools*
The moose likes Performance and the fly likes Performance tips for the Java final keyword Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Performance
Bookmark "Performance tips for the Java final keyword" Watch "Performance tips for the Java final keyword" New topic
Author

Performance tips for the Java final keyword

RaviNada Kiran
Ranch Hand

Joined: Jan 30, 2009
Posts: 528
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 .


If you want something you never had do something which you had never done
Nitesh Kant
Bartender

Joined: Feb 25, 2007
Posts: 1638

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:



will be converted to:



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


apigee, a better way to API!
RaviNada Kiran
Ranch Hand

Joined: Jan 30, 2009
Posts: 528
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
Rancher

Joined: Oct 12, 2008
Posts: 1369
    
    1

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.



[List of FAQs] | [Android FAQ] | [Samuh Varta]
RaviNada Kiran
Ranch Hand

Joined: Jan 30, 2009
Posts: 528
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
Ranch Hand

Joined: Feb 18, 2008
Posts: 128
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
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16141
    
  21

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.


Customer surveys are for companies who didn't pay proper attention to begin with.
Gaurav Arora
Ranch Hand

Joined: Aug 13, 2007
Posts: 35
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
Ranch Hand

Joined: Feb 18, 2008
Posts: 128
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
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
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
Ranch Hand

Joined: Feb 18, 2008
Posts: 128
Hmm.. okay, I took it literally, but if we see it as an example/explanation then you (and Nitesh) are right
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4659
    
    5

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
Rancher

Joined: Oct 12, 2008
Posts: 1369
    
    1

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.
 
 
subject: Performance tips for the Java final keyword