performance surprise with Object.hashCode()

[Vitaly Davidovich]

I don't think burning away the one base class on such a thing is worth it.
For classes that have fast hash (vast majority, based on my experience)
there's no need for this.  Ones with expensive hash can decide to cache or
not on a case by case basis (e.g. it may be expensive but infrequently
requested and thus possibly increasing mem footprint isn't worth it).

Sent from my phone
On May 13, 2013 6:47 PM, "Andy Nuss" <andrew_nuss at yahoo.com> wrote:

> Assuming that when this CR is successfully completed, you guys are
> expecting a virtual call to Integer.hashCode() to be a quite a bit faster
> than the Object-version, and faster still as machines get faster, then I
> propose you introduce a new class to java.lang package:
>
> public class ObjectThatCachesHash extends Object {
>      private int      hash;          // no need to be volatile!
>
>      public int hashCode ()
>      {
>           if (hash == 0)
>               hash = super.hashCode();
>           return hash;
>      }
> }
>
> Then, because hashing is always supposed to be idempotent, objects
> throughout the JDK such as java.lang.Class that are often hashkeys and have
> a big footprint, and for which it is expected that the same instance's
> hashCod() will be called frequently enough to be in the memory cache, you
> could improve hashCode() for these too:
>
> public Class extends ObjectThatCachesHash {
>
>     // no further change needed to hashCode(), but this version from ObjectThatCachesHash
> will
>     // be faster than System.identityHashCode()
> }
>
> Does this idea have any value?
>
>   ------------------------------
>  *From:* Vitaly Davidovich <vitalyd at gmail.com>
> *To:* Aleksey Shipilev <aleksey.shipilev at oracle.com>
> *Cc:* hotspot compiler <hotspot-compiler-dev at openjdk.java.net>; Andy Nuss
> <andrew_nuss at yahoo.com>
> *Sent:* Monday, May 13, 2013 2:25 PM
> *Subject:* Re: performance surprise with Object.hashCode()
>
> Yeah, changing Object.hashCode seems better.  I'm no expert, but I don't
> see anything in libraryCall.cpp that makes use of inline cache (most
> intrinsics are for statically known things though), so curious how this can
> be fixed without turning things upside down in there.  If we were to
> redirect to S.iHM I wonder if we'd get the desired effect for free.
> Sent from my phone
> On May 13, 2013 4:53 PM, "Aleksey Shipilev" <aleksey.shipilev at oracle.com>
> wrote:
>
> On 05/14/2013 12:42 AM, Vitaly Davidovich wrote:
> > I think the point is that intrinsic only helps when you're calling
> > Object.hashCode.  For classes with override, it's a loss.  I think what
> > you want here is an inline cache with Object.hashCode in there but also
> > whatever other frequent receiver(s) you have.  With Andy's suggestion,
> > you'd get an inline cache with one possible target being
> > System.identityHashcode but also perhaps an inline of Integer (in this
> > scenario).
>
> Yes, I can see that.
>
> Assume we change the Object.hashCode to call System.identityHashCode()
> on Java side, and let the runtime to optimize the S.iHM into the
> intrinsic to evade the native call. This will fix the immediate problem,
> but the VM changes would be more pervasive: you need to disable the
> intrinsic for Object.hashCode, you need to make sure it had inlined
> S.iHM, etc.
>
> If we are talking about fixing the JDK, then it's way better to fix the
> Object.hashCode intrinsic itself. It really seems a glitch in that C2
> intrinsic code. I'll go ahead and submit the CR for this.
>
> Thanks, that was an interesting issue to untangle.
>
> -Aleksey.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130513/4bf474cc/attachment.html