performance surprise with Object.hashCode()

[Andy Nuss]

I'm doing 10 gig iterations, between the timestamp accesses.  So I don't see how nanoTime would make any difference.  I do a loop of 10000 calls to the summing function just before each of the 3 tests to ensure that hotspot and the L1 caches are warmed up fully.


I use a long iteration variable, not only to get a huge number of iterations, but to make sure in the 3rd test that the loop is not hoisted away.


As to the branch mispredict, note that the mask for the summing functions is 31, which means that only the first 32 elements of the arrays will ever be accessed in the looping function, and in the 2nd array, the first 32 elements are all Integer.  I mixed Integer and Object in that 2nd array just to be sure than hotspot didn't outsmart me.  Again, there are no branch mispredicts anywhere.



________________________________
 From: Vitaly Davidovich <vitalyd at gmail.com>
To: Andy Nuss <andrew_nuss at yahoo.com> 
Cc: hotspot compiler <hotspot-compiler-dev at openjdk.java.net> 
Sent: Monday, May 13, 2013 10:45 AM
Subject: Re: performance surprise with Object.hashCode()
 


You should use System.nanoTime instead of currentTimeMillis.
In your 2nd run, you're going to either get a branch mispredict when it switches from Integer to Object (shouldn't be big contributor though) or you're possibly causing JIT to do type checks on each iteration to see which hashCode to call (assuming there's an inline cache installed).
Why don't you make the array typed Object but fill it only with Integers? Why are you mixing in two types?
Sent from my phone
On May 13, 2013 1:30 PM, "Andy Nuss" <andrew_nuss at yahoo.com> wrote:

Here's my benchmarking code.  I don't see at all why a virtual call to Integer.hashCode is so much slower than the base line loop skeleton + inline access to member value of Integer (3rd case) + 0.5 nanos of vtable call (measured in a separate benchmark).
>
>
>To me, this indicates a serious design flaw in so-called intrinsic call on modern fast machines that could be corrected (were it possible) by making hashCode() a normal non-native function that forwards to System.identityHashCode().
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130513/5c174a26/attachment.html