the final say in performance

[Frank]

Just curious if anyone knows how well a compiler can optimize a variable
once it has been declared final. I know that, final declarations for
classes can be optimized to allow faster method invocation, and final
fields can be optimized especially with regard to threading
implementations.
Further, a good compiler should recognize that

for (long i=0; i<i_max; i++) {
int x0=//something
//do stuff here
}

should get compiled as
{
int x0;
for (long i=0; i<i_max; i++) {
x0=//something
//do stuff here
}}

to save stack activity. However, I recently found it usefull to start
writing some code as:

for (long i=0; i<i_max; i++) {
final int x0=//something - final just for the scope of the loop
//do stuff with (but not to!) x0 here
}

Can anyone comment on how this might affect the performance of this loop?
Also, sometimes it usefull to declare method parameters as final:

public void myMethod(final int x) {...}

I guess I'm just wondering what kind of optimizations the compiler can (or
can't) do with these declarations... and if it sees that a non-final
parameter is not changed, will it optimize the parameter as final? Or is
final, in this case, nothing more than a checkpoint to force an error on
assignment?

Thanks,

Frank

 

[Tim Tyler]

: I know that, final declarations for classes can be optimized to allow
: faster method invocation, and final fields can be optimized especially
: with regard to threading implementations.

``A survey of programmers using the Java programming language will quickly
reveal that many avoid using fully virtual methods (and also write
bigger methods) because they believe that every virtual method
invocation entails a significant performance penalty. Ubiquitous,
fine-grain use of virtual methods, such as methods that are not
"static" or "final" in the Java programming language, is extremely
important to the construction of highly reusable classes because each
such method acts as a "hook" that allows new subclasses to modify the
behavior of the superclass.

Because the Java HotSpot VM can automatically inline the vast majority
of virtual method invocations, this performance penalty is
dramatically reduced, and in many cases eliminated altogether.''

- http://java.sun.com/products/hotspot/whitepaper.html

See also "Dynamic Deoptimization" - on:

http://java.sun.com/products/hotspo...tspot_v1.4.1/Java_HSpot_WP_v1.4.1_1002_4.html

....and - I suppose - "Java theory and practice: Urban performance legends" on:

http://www-106.ibm.com/developerworks/java/library/j-jtp04223.html?ca=dgr-lnxw01JavaUrbanLegends

 

[xarax]

: I know that, final declarations for classes can be optimized to allow
: faster method invocation, and final fields can be optimized especially
: with regard to threading implementations.

``A survey of programmers using the Java programming language will quickly
reveal that many avoid using fully virtual methods (and also write
bigger methods) because they believe that every virtual method
invocation entails a significant performance penalty. Ubiquitous,
fine-grain use of virtual methods, such as methods that are not
"static" or "final" in the Java programming language, is extremely
important to the construction of highly reusable classes because each
such method acts as a "hook" that allows new subclasses to modify the
behavior of the superclass.

Because the Java HotSpot VM can automatically inline the vast majority
of virtual method invocations, this performance penalty is
dramatically reduced, and in many cases eliminated altogether.''

/snip/

The Java Lang and Java Virtual Machine specifications also indicate
(i.e., encourage) JVM implementations to cache somehow the resolution
of a virtual method look-up so that subsequent invocations of the
same method signature on the same object reference will be faster.

Also, there is no "stack activity" when declaring local variables
within a local block.

Example 1:

for(x = 0; x < 10; ++x)
{
int y;
// stuff
}

Example 2:
{
int y;
for(x = 0; x < 10; ++x)
{
// stuff
}
}

There is no difference in "stack activity" between the above
two examples. The compiler tracks stack slot usage throughout
the entire method and reserves enough stack space for the
method. The local variable "y" will be assigned to a stack
slot that will be available when the declaring block is
encountered at runtime. A new stackframe is NOT allocated
when a local block with local variables is encountered. That
would be a hugely inefficient JVM/compiler implementation.