Originally found here:
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2013-May/010521.html
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2013-May/010523.html

With the attached test case
(java -jar microbenchmarks.jar ".*Andy.*" -wi 1 -r 1 -i 5)

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

"i_i" test: Integer i = new Integer(42); i.hashCode();
"o_o" test: Object o = new Object(); o.hashCode();
"o_i" test: Object o = new Integer(42); o.hashCode();

Note the "o_i" test is getting slower with the intrinsic turned on. Disassembly seems to show the inlined intrinsic for Object.hashCode had forced us to go through the slow-path v-call to Integer.hashCode. This does not happen if intrinsic is turned off, as we devirtualize successfully.