Eclipse generated hashCode() and Compiler Efficiency

[Robert Klemme]

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/T1;
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 do
(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_edition/html/Overview.doc.html#7143

Kind regards

robert

 

[lewbloch]

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/T1;
   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 do
(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_edition/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?

 

[jaap]

Eclipse's compiler has an option whether to retain or eliminate unused
local variables. How do you have that switch set?

Don't forget the JIT compiler, she makes your code beautiful to run (and
awkward to read, but you never do).

Jaap

 

[Roedy Green]

Is this an optimization they didn't bother to do
(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.

Almost no optimisation is done at the byte code level. It is all done
later when hotspotting. Ironically, it is possible that if you get
too clever and optimise the byte code, then later optimisers could
miss standard patterns and hence fail in their optimisations.

--
Roedy Green Canadian Mind Products
http://mindprod.com
One of the curses of the computer age is manufacturers now design
home appliances to die on the very day the warranty expires.
It is deliberate waste in the service of mindless profit.

 

[Robert Klemme]

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