performance surprise with Object.hashCode()

[Aleksey Shipilev]

What difference does it make if the Object.hashCode implementation is
native? System.identityHashCode is native as well, so the Java
trampoline would not help. In fact, I think both these guys are getting
to call the same VM method in the end.

See the the performance result for o_o with intirinsic turned off: 27ns
vs. 2ns. That's the native call to VM for getting the hashcode. That's
the reason why do we have Object.hashCode intrinsified.

-Aleksey.

On 05/14/2013 12:18 AM, Andy Nuss wrote:
> Can you guys tell me, does a pure Object instance even have a vtable? 
> Is there any reason why hotspot is special-casing the object hashCode()
> function thru "instrinsics", when instead it could make hashCode()
> non-native, and forward by default to the equivalent of
> System.identityHashCode()?
> 
> 
> ------------------------------------------------------------------------
> *From:* Aleksey Shipilev <aleksey.shipilev at oracle.com>
> *To:* Vitaly Davidovich <vitalyd at gmail.com>
> *Cc:* hotspot compiler <hotspot-compiler-dev at openjdk.java.net>; Andy
> Nuss <andrew_nuss at yahoo.com>
> *Sent:* Monday, May 13, 2013 1:04 PM
> *Subject:* Re: performance surprise with Object.hashCode()
> 
> On 05/14/2013 12:00 AM, Vitaly Davidovich wrote:
>> I'm comparing i_i vs o_i difference when intrinsic is enabled/disabled.
>> Based on your results, when intrinsic is disabled the o_i case is
>> marginally slower than i_i, whereas it's noticeably slower otherwise.
> 
> Ah yes. That's because i_i is perfectly devirtualized without any
> typechecks (re-reading my original note, there is mention of typecheck,
> disregard that, see the hot loop in assembly, it is perfect). o_i
> without intrinsic has the typecheck nevertheless, and we are wasting
> some of the time there. o_i with intrinsic seems to lose the
> devirtualization completely.
> 
> -Aleksey.
> 
>