performance surprise with Object.hashCode()

[Vitaly Davidovich]

Yeah, changing Object.hashCode seems better.  I'm no expert, but I don't
see anything in libraryCall.cpp that makes use of inline cache (most
intrinsics are for statically known things though), so curious how this can
be fixed without turning things upside down in there.  If we were to
redirect to S.iHM I wonder if we'd get the desired effect for free.

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

> On 05/14/2013 12:42 AM, Vitaly Davidovich wrote:
> > 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).
>
> Yes, I can see that.
>
> Assume we change the Object.hashCode to call System.identityHashCode()
> on Java side, and let the runtime to optimize the S.iHM into the
> intrinsic to evade the native call. This will fix the immediate problem,
> but the VM changes would be more pervasive: you need to disable the
> intrinsic for Object.hashCode, you need to make sure it had inlined
> S.iHM, etc.
>
> If we are talking about fixing the JDK, then it's way better to fix the
> Object.hashCode intrinsic itself. It really seems a glitch in that C2
> intrinsic code. I'll go ahead and submit the CR for this.
>
> Thanks, that was an interesting issue to untangle.
>
> -Aleksey.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130513/b3c573e9/attachment.html