Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Java (http://www.velocityreviews.com/forums/f30-java.html)
-   -   Eclipse generated hashCode() and Compiler Efficiency (http://www.velocityreviews.com/forums/t750882-eclipse-generated-hashcode-and-compiler-efficiency.html)

Robert Klemme 07-04-2011 11:07 AM

Eclipse generated hashCode() and Compiler Efficiency
 
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/....doc.html#7143

Kind regards

robert

lewbloch 07-04-2011 11:13 AM

Re: Eclipse generated hashCode() and Compiler Efficiency
 
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/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/...l/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?

--
Lew

jaap 07-04-2011 03:43 PM

Re: Eclipse generated hashCode() and Compiler Efficiency
 
On 04-07-11 13:13, schreef lewbloch:
> 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/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/...l/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?
>
> --
> Lew


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

Jaap

Roedy Green 07-04-2011 03:54 PM

Re: Eclipse generated hashCode() and Compiler Efficiency
 
On Mon, 4 Jul 2011 04:07:51 -0700 (PDT), Robert Klemme
<shortcutter@googlemail.com> wrote, quoted or indirectly quoted
someone who said :

> 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 07-06-2011 07:20 AM

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/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/...l/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


All times are GMT. The time now is 08:26 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.