博士

ロボ子、JDK 25で`String`クラスの`String::hashCode`関数のパフォーマンスが改善されたらしいのじゃ！

ロボ子

それはすごいですね、博士！具体的にはどのような改善があったのでしょうか？

博士

`String`をキーとして使う変更不可能な`Map`で、パフォーマンスが上がるらしいぞ。例えば、設定ファイルとかでよく使うじゃろ？

ロボ子

確かに、設定ファイルでは文字列をキーにしたMapをよく使いますね。それが速くなるのは嬉しいです。

博士

そうじゃろ！`String`のハッシュコードは最初に作られた時は不明で、最初の呼び出しで計算されるんじゃ。そして、`String.hash`というプライベートフィールドに格納される。

ロボ子

`String.hash`フィールドに`@Stable`アノテーションが付与されたのがミソみたいですね。

博士

そう！`@Stable`は、VMに「このフィールドは一度読み取ったら、二度と変わらないから安心してね」って伝えるためのものじゃ。

ロボ子

なるほど。一度ハッシュコードを計算したら、その値をずっと使い続けるということですね。

博士

そういうことじゃ！例えば、文字列"malloc"のハッシュコードは常に`-1081483544`になる。

ロボ子

ハッシュコードがゼロだと、定数畳み込みが機能しないというのはどういうことでしょうか？

博士

良い質問じゃな、ロボ子！コンパイラが最適化するときに、ハッシュコードがゼロだと、その値を使って計算できないんじゃ。でも、1〜6文字の文字列ならハッシュコードはゼロにならないから、安心して良いぞ。

ロボ子

`@Stable`アノテーションは内部JDKコードにしか使えないんですね。ユーザーコードで直接使うことはできないんですか？

博士

今はまだじゃな。でも、JEP 502で、ユーザーコードも`@Stable`フィールドから間接的にメリットを得られるようにする予定らしいぞ。

ロボ子

それは楽しみです！

博士

JDK 25をダウンロードして、パフォーマンスの向上を確かめてみると良いぞ！ベンチマークの結果では、`StringHashCodeStatic.nonZero`の平均実行時間がJDK 24では4.632ns/opだったのが、JDK 25では0.571ns/opに改善されたらしい。

ロボ子

すごい改善ですね！

博士

じゃろじゃろ？ところでロボ子、`String`の`hash`フィールドが`@Stable`になったということは、もう`不安定`とは言えないのじゃ。

ロボ子

博士、それ、ただのダジャレですね…。