performance surprise with Object.hashCode()

Aleksey Shipilev aleksey.shipilev at oracle.com
Mon May 13 11:46:47 PDT 2013


On 05/13/2013 10:35 PM, Aleksey Shipilev wrote:
> Note that the code generated in o_o and o_i cases are structurally
> indistinguishable, but o_i naturally goes through the slow path. I
> wonder why we are losing the information about receiver type being the
> integer in o_i case, and skip the proper devirtualization...

In fact, I *do* think the Object.hashCode intrinsic plays a trick on us
here.

Linux x86_64, JDK 8b88:

OOB:
  o.s.g.a.AndyBench.eee:  0.997 +- 0.020 nsec/op
  o.s.g.a.AndyBench.i_i:  1.288 +- 0.035 nsec/op
  o.s.g.a.AndyBench.o_o:  2.709 +- 0.129 nsec/op
  o.s.g.a.AndyBench.o_i:  4.925 +- 0.098 nsec/op

-XX:+UnlockDiagnosticVMOptions -XX:DisableIntrinsic=_hashCode:
  o.s.g.a.AndyBench.eee:  0.992 +- 0.012 nsec/op
  o.s.g.a.AndyBench.i_i:  1.288 +- 0.024 nsec/op
  o.s.g.a.AndyBench.o_o: 27.888 +- 1.326 nsec/op
  o.s.g.a.AndyBench.o_i:  1.623 +- 0.033 nsec/op

See how o_i case gets to perform much better. o_o naturally takes the
hit with the intrinsic disabled.

-Aleksey.


More information about the hotspot-compiler-dev mailing list