performance surprise with Object.hashCode()

[Vitaly Davidovich]

I think the point is that intrinsic only helps when you're calling
Object.hashCode.  For classes with override, it's a loss.  I think what you
want here is an inline cache with Object.hashCode in there but also
whatever other frequent receiver(s) you have.  With Andy's suggestion,
you'd get an inline cache with one possible target being
System.identityHashcode but also perhaps an inline of Integer (in this
scenario).

Sent from my phone
On May 13, 2013 4:33 PM, "Aleksey Shipilev" <aleksey.shipilev at oracle.com>
wrote:

> 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.
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130513/bf0afb68/attachment-0001.html