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. Also this reminds me of https://bugs.openjdk.org/browse/JDK-8332249 - maybe Method::hashCode was hot because the string hash code could not fold. Regards, Chen ________________________________ 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
