Hi Chen, I think we can choose an arbitrary non-zero number and assign it to the `hash` field when the calculated hash is 0.
This has two costs: 1. When the hash is 0, both the hash and hashIsZero fields need to be written after the hash is calculated; 2. When the hash is really just that number, it cannot be constant folded. Considering this allows the empty string hash to be constant folded, I guess it's worth it. Glavo On Fri, Apr 11, 2025 at 2:16 AM Chen Liang <chen.l.li...@oracle.com> wrote: > 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 >
