performance surprise with Object.hashCode()

[Chuck Rasbold]

On Mon, May 13, 2013 at 2:41 PM, Aleksey Shipilev <
aleksey.shipilev at oracle.com> wrote:

> On 05/14/2013 01:31 AM, John Rose wrote:
> > Something about this code is overcoming the intended effect of
> > UseTypeProfile.  Often it is a lack of warmup.  In this case it may
> > be a bug in C2, if find_intrinsic etc. is used to generate graph
> > before the type profile is used (TypeProfileMajorReceiverPercent
> > etc.).
>
> Warmup is fine; seems to be the performance bug in the C2. I submitted
> CR 8014447, need someone with the expertise in that part of C2 to look
> at that thing. The test is there as well.
>
>
It seems to me that C2 is preferring to intrinsify the general
Object.hashCode()
when it would do better inline to Integer.hashCode() if the majority
receiver indicates it is appropriate to do so.

In Compile::call_generator(), one could delay the return of the
intrinsic's cg until after the type_profile is considered. But you
would have to be careful to not inline a bytecoded method if an
intrinsic was already found.

It really isn't very many lines of code, but thorough regression
performance testing would be a must because the logic in doCall.cpp
can be subtle.


> -Aleksey.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130514/6dd9779c/attachment-0001.html