java.lang.String hashCode and @Stable ?

[Chen Liang]

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-retn at openjdk.org> on behalf of Remi Forax <forax at univ-mlv.fr>
Sent: Thursday, April 10, 2025 4:18 AM
To: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: java.lang.String hashCode and @Stable ?

Question,
why String.hash and String.hashIsZero are not declared @Stable ?

regards,
Rémi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250410/77d92ca0/attachment.htm>