> From: "Chen Liang" <chen.l.li...@oracle.com> > To: "Remi Forax" <fo...@univ-mlv.fr>, "core-libs-dev" > <core-libs-dev@openjdk.org> > Sent: Thursday, April 10, 2025 8:16:39 PM > Subject: Re: java.lang.String hashCode and @Stable ?
> Hi Remi, > I think this is probably due to these fields being added too early - the > stable > on string byte array is also added lately. > 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. > A solution may be to change hashIsZero 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. yes, and obviously, it has to be done without introducing a perf regression if the String is not constant folded. I think it would be nice to try that as a follow-up of JDK-8354300. > Also this reminds me of [ https://bugs.openjdk.org/browse/JDK-8332249 | > https://bugs.openjdk.org/browse/JDK-8332249 ] - maybe Method::hashCode was hot > because the string hash code could not fold. Usually in framework like Spring, Method are cached either by the framework or by java.lang.Class own cache so the Method itself is rarely a constant. > Regards, Chen regards, Rémi > From: core-libs-dev <core-libs-dev-r...@openjdk.org> on behalf of Remi Forax > <fo...@univ-mlv.fr> > Sent: Thursday, April 10, 2025 4:18 AM > To: core-libs-dev <core-libs-...@openjdk.java.net> > Subject: java.lang.String hashCode and @Stable ? > Question, > why String.hash and String.hashIsZero are not declared @Stable ? > regards, > Rémi
