java.lang.String hashCode and @Stable ?

[Glavo]

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.liang at 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-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/20250411/2a2761d2/attachment.htm>