Re: Eclipse generated hashCode() and Compiler Efficiency
On 4 Jul., 13:13, lewbloch <lewbl...@gmail.com> wrote:
On Jul 4, 4:07 am, Robert Klemme <shortcut...@googlemail.com> wrote:
Hi,
Eclipse generates hashCode() methods like this for a class with a
single int field "i":
@Override
public int hashCode() {
final int prime = 31;
int result = 1;
result = prime * result + i;
return result;
}
I always found it weird to define the constant "prime" at method
level. I wanted to know what happens and disassembled with
$ javap -c -verbose -private -classpath classes bytecode.T1
This is what I got for the method:
public int hashCode();
Code:
Stack=2, Locals=3, Args_size=1
0: bipush 31
2: istore_1
3: iconst_1
4: istore_2
5: bipush 31
7: iload_2
8: imul
9: aload_0
10: getfield #18; //Field i:I
13: iadd
14: istore_2
15: iload_2
16: ireturn
LineNumberTable:
line 9: 0
line 10: 3
line 11: 5
line 12: 15
LocalVariableTable:
Start Length Slot Name Signature
0 17 0 this Lbytecode/T=
1;
3 14 1 prime I
5 12 2 result I
(This was from Eclipse compiler but Sun's javac yields the same albeit
with a different ordering of constants.)
Apart from other inefficiencies the weird thing is that in lines 0 and
2 the constant 31 is stored in local variable 1 ("prime") although it
is never read again. Is this an optimization they didn't bother to d=
o
(or left for the JVM) or is there any reason why the local variable
must be there? So far I could not find any hints in JLS or JVM spec.
You can find the full examples here - including a variant where
"prime" is a constant on class level:https://gist.github.com/1063153
Instruction reference:http://java.sun.com/docs/books/jvms/second_editio=
n/html/Overview.doc....
Kind regards
Eclipse's compiler has an option whether to retain or eliminate unused
local variables. How do you have that switch set?
Good point! That was set at default ("preserve unused locals"). When
toggled I get this:
public int hashCode();
Code:
Stack=2, Locals=2, Args_size=1
0: iconst_1
1: istore_1
2: bipush 31
4: iload_1
5: imul
6: aload_0
7: getfield #18; //Field i:I
10: iadd
11: istore_1
12: iload_1
13: ireturn
LineNumberTable:
line 10: 0
line 11: 2
line 12: 12
LocalVariableTable:
Start Length Slot Name Signature
0 14 0 this Lbytecode/T1;
2 12 1 result I
What I find puzzling is that the compiler does only half of an
optimization: the constant is used but the int is still kept around.
That somehow seems inconsequential. But I guess the scenario is
deemed too rare to be worth a separate treatment in the compiler since
the JVM will likely kill this local anyway.
Kind regards
robert