<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br></div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Glavo" <zjx001202@gmail.com><br><b>To: </b>"Chen Liang" <chen.l.liang@oracle.com><br><b>Cc: </b>"Remi Forax" <forax@univ-mlv.fr>, "core-libs-dev" <core-libs-dev@openjdk.org><br><b>Sent: </b>Thursday, April 10, 2025 8:54:57 PM<br><b>Subject: </b>Re: java.lang.String hashCode and @Stable ?<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Chen,<br><div>I think we can choose an arbitrary non-zero number and assign it to the `hash` field when the calculated hash is 0.</div></div></div></div></div></div></div></div></blockquote><div><br data-mce-bogus="1"></div><div>Usually yes, for String no.</div><div>String.hashCode() computation is fully specified in the javadoc so changing the returned value is not a backward compatible change.</div><div><br data-mce-bogus="1"></div><div>When you compile a switch(String) the compiler computes the hashCode of the cases and switch on those values, so those hashCode values are inserted in the bytecode.</div><div>If you change the algorithm of String.hashCode(), the runtime value and the compiled value will not be the same.<div><br data-mce-bogus="1"></div></div><div>regards,</div><div>Rémi</div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"></div></div></div></div></div></div></blockquote><div><br></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br><div>Glavo</div></div></div></div></div></div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Apr 11, 2025 at 2:16 AM Chen Liang <<a href="mailto:chen.l.liang@oracle.com" target="_blank">chen.l.liang@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-1225089547150575249">
<div dir="ltr">
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
Hi Remi,</div>
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
I think this is probably due to these fields being added too early - the stable on string byte array is also added lately.</div>
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
That said, I don't think adding stable on both fields completely resolves the constant folding issues around string hash code. The current code can only constant fold non-zero hash; a zero hash is folded to a read to hash field, which cannot fold further because
it's a read of the default value from a stable field.</div>
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
A solution may be to change <code>hashIsZero</code> to a byte field indicating 3 states - hash unset (0), hash computed to field, hash computed and is zero. This allows the zero hash to constant fold as well at the cost of non-constant hash access performance,
as now there are two reads.</div>
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
Also this reminds me of <a href="https://bugs.openjdk.org/browse/JDK-8332249" target="_blank">https://bugs.openjdk.org/browse/JDK-8332249</a> - maybe Method::hashCode was hot because the string hash code could not fold.</div>
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
Regards, Chen</div>
<hr style="display:inline-block;width:98%">
<div id="m_-9027240860956498526divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> core-libs-dev <<a href="mailto:core-libs-dev-retn@openjdk.org" target="_blank">core-libs-dev-retn@openjdk.org</a>> on behalf of Remi Forax <<a href="mailto:forax@univ-mlv.fr" target="_blank">forax@univ-mlv.fr</a>><br><b>Sent:</b> Thursday, April 10, 2025 4:18 AM<br><b>To:</b> core-libs-dev <<a href="mailto:core-libs-dev@openjdk.java.net" target="_blank">core-libs-dev@openjdk.java.net</a>><br><b>Subject:</b> java.lang.String hashCode and @Stable ?</font>
<div> </div>
</div>
<div><font size="2"><span style="font-size:11pt"><div>Question,<br>
why String.hash and String.hashIsZero are not declared @Stable ?<br>
<br>
regards,<br>
Rémi<br>
</div></span></font></div>
</div>
</div></blockquote></div><br></blockquote></div></div></body></html>