Hi, this appears to be unintentionally left out. I've filed a bug[1].
While marked as an @IntrinsicCandidate, I can't see that HotSpot/C2 is actually intrinsifying this constructor. The signature is used for some pattern matching in the legacy stringopts.cpp code, though. So the trivial fix should help a bit. Thanks Claes [1] https://bugs.openjdk.java.net/browse/JDK-8277606 On 2021-11-22 22:20, Japris Pogrammer wrote:
According to openjdk/jdk [1] current copy-constructor of String class does not copy the value of hashIsZero field which may lead to 0-hash being recalculated on copy even if it is known to be 0. Could you please tell me if I am right with this point or if this behaviour is intentional? If this is actually a bug then I am ready to propose a trivial fix for it[2]. [1]: https://github.com/openjdk/jdk/blob/05a9a51dbfc46eb52bc28f1f9a618c75ee2597e9/src/java.base/share/classes/java/lang/String.java#L259-L264 [2]: https://github.com/JarvisCraft/jdk/tree/String-copy-zero-hashCode
