<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: "Calibri Light", "Helvetica Light", sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hi Remi,</div>
<div class="elementToProof" 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 class="elementToProof" style="font-family: "Calibri Light", "Helvetica Light", sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" 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 class="elementToProof" 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 class="elementToProof" style="font-family: "Calibri Light", "Helvetica Light", sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" 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">https://bugs.openjdk.org/browse/JDK-8332249</a> - maybe Method::hashCode was hot because the string hash code could not fold.</div>
<div class="elementToProof" style="font-family: "Calibri Light", "Helvetica Light", sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: "Calibri Light", "Helvetica Light", sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Regards, Chen</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> core-libs-dev <core-libs-dev-retn@openjdk.org> on behalf of Remi Forax <forax@univ-mlv.fr><br>
<b>Sent:</b> Thursday, April 10, 2025 4:18 AM<br>
<b>To:</b> core-libs-dev <core-libs-dev@openjdk.java.net><br>
<b>Subject:</b> java.lang.String hashCode and @Stable ?</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">Question,<br>
why String.hash and String.hashIsZero are not declared @Stable ?<br>
<br>
regards,<br>
Rémi<br>
</div>
</span></font></div>
</body>
</html>