performance surprise with Object.hashCode()

Vitaly Davidovich vitalyd at
Mon May 13 11:20:56 PDT 2013

I'm reading this on my phone, missed the mask.

So how are you getting 0.5ns for vcall? You mention that's elsewhere but
how are you computing that?

Are you able to capture the assembly that's generated for your test cases?

Sent from my phone
On May 13, 2013 2:14 PM, "Andy Nuss" <andrew_nuss at> wrote:

> By the way, I reran the test, filling the 2nd array with only Integer, and
> got the same result.  So your 2 offered explanations do not account for the
> surprising performance slowness of subclassing hashCode().
>   ------------------------------
>  *From:* Vitaly Davidovich <vitalyd at>
> *To:* Andy Nuss <andrew_nuss at>
> *Cc:* hotspot compiler <hotspot-compiler-dev at>
> *Sent:* Monday, May 13, 2013 10:45 AM
> *Subject:* Re: performance surprise with Object.hashCode()
> You should use System.nanoTime instead of currentTimeMillis.
> In your 2nd run, you're going to either get a branch mispredict when it
> switches from Integer to Object (shouldn't be big contributor though) or
> you're possibly causing JIT to do type checks on each iteration to see
> which hashCode to call (assuming there's an inline cache installed).
> Why don't you make the array typed Object but fill it only with Integers?
> Why are you mixing in two types?
> Sent from my phone
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the hotspot-compiler-dev mailing list