<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><span>Assuming that </span><span><span>when this CR is successfully completed, </span>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:<br><br>public class ObjectThatCachesHash extends Object {<br>&nbsp;&nbsp;&nbsp;&nbsp; private int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; hash;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // no need to be volatile!<br><br>&nbsp;&nbsp;&nbsp;&nbsp; public int hashCode ()<br>&nbsp;&nbsp;&nbsp;&nbsp; {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (hash == 0)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; hash = super.hashCode();<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 return hash;<br>&nbsp;&nbsp;&nbsp;&nbsp; }<br>}<br><br>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:<br><br>public Class extends ObjectThatCachesHash {<br><br>&nbsp;&nbsp;&nbsp; // no further change needed to hashCode(), but this version from </span><span><span>ObjectThatCachesHash </span>will<br>&nbsp;&nbsp;&nbsp; // be faster than System.identityHashCode()<br>}<br><br>Does this idea have any value?<br></span><div><br></div>  <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div dir="ltr"> <hr size="1">  <font face="Arial" size="2"> <b><span
 style="font-weight:bold;">From:</span></b> Vitaly Davidovich &lt;vitalyd@gmail.com&gt;<br> <b><span style="font-weight: bold;">To:</span></b> Aleksey Shipilev &lt;aleksey.shipilev@oracle.com&gt; <br><b><span style="font-weight: bold;">Cc:</span></b> hotspot compiler &lt;hotspot-compiler-dev@openjdk.java.net&gt;; Andy Nuss &lt;andrew_nuss@yahoo.com&gt; <br> <b><span style="font-weight: bold;">Sent:</span></b> Monday, May 13, 2013 2:25 PM<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: performance surprise with Object.hashCode()<br> </font> </div> <div class="y_msg_container"><br><div id="yiv8471196081"><div dir="ltr">Yeah, changing Object.hashCode seems better.&nbsp; 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.&nbsp; If we were to redirect to S.iHM I wonder if
 we'd get the desired effect for free.</div>

<div dir="ltr">Sent from my phone</div>
<div class="yiv8471196081gmail_quote">On May 13, 2013 4:53 PM, "Aleksey Shipilev" &lt;<a rel="nofollow" ymailto="mailto:aleksey.shipilev@oracle.com" target="_blank" href="mailto:aleksey.shipilev@oracle.com">aleksey.shipilev@oracle.com</a>&gt; wrote:<br><blockquote class="yiv8471196081gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On 05/14/2013 12:42 AM, Vitaly Davidovich wrote:<br>
&gt; I think the point is that intrinsic only helps when you're calling<br>
&gt; Object.hashCode. &nbsp;For classes with override, it's a loss. &nbsp;I think what<br>
&gt; you want here is an inline cache with Object.hashCode in there but also<br>
&gt; whatever other frequent receiver(s) you have. &nbsp;With Andy's suggestion,<br>
&gt; you'd get an inline cache with one possible target being<br>
&gt; System.identityHashcode but also perhaps an inline of Integer (in this<br>
&gt; scenario).<br>
<br>
Yes, I can see that.<br>
<br>
Assume we change the Object.hashCode to call System.identityHashCode()<br>
on Java side, and let the runtime to optimize the S.iHM into the<br>
intrinsic to evade the native call. This will fix the immediate problem,<br>
but the VM changes would be more pervasive: you need to disable the<br>
intrinsic for Object.hashCode, you need to make sure it had inlined<br>
S.iHM, etc.<br>
<br>
If we are talking about fixing the JDK, then it's way better to fix the<br>
Object.hashCode intrinsic itself. It really seems a glitch in that C2<br>
intrinsic code. I'll go ahead and submit the CR for this.<br>
<br>
Thanks, that was an interesting issue to untangle.<br>
<br>
-Aleksey.<br>
</blockquote></div></div><br><br></div> </div> </div>  </div></body></html>