performance surprise with Object.hashCode()
vitalyd at gmail.com
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 yahoo.com> 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 gmail.com>
> *To:* Andy Nuss <andrew_nuss at yahoo.com>
> *Cc:* hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
> *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