performance surprise with Object.hashCode()
Aleksey Shipilev
aleksey.shipilev at oracle.com
Mon May 13 13:53:21 PDT 2013
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.
More information about the hotspot-compiler-dev
mailing list