Hi all, I think the key takeaway here is that we should reduce the number of intrinsics for easier maintenance. With the same number of unsafe Java methods, it is still feasible to reduce the number of distinct intrinsics simply for the reduced maintenance cost. For example, the toBytes and getChars of StringUTF16 both have intrinsics. However, in essence, they are just two array copy functions - it would be more reasonable for hotspot to implement a generic array copy intrinsic that StringUTF16 can use instead. Such an intrinsic may take place on Unsafe.copyMemory itself, or may be somewhere else.
Chen ________________________________ From: core-libs-dev <core-libs-dev-r...@openjdk.org> on behalf of wenshao <shaojin.we...@alibaba-inc.com> Sent: Wednesday, July 30, 2025 9:45 PM To: Roger Riggs <roger.ri...@oracle.com>; core-libs-dev <core-libs-dev@openjdk.org> Subject: 回复：Reuse the StringUTF16::putCharsSB method instead of the Intrinsic in the StringUTF16::toBytes Thanks to Roger Riggs for suggesting that the code should not be called with Unsafe.uninitializedArray. After replacing it with `new byte[]` and running `StringConstructor.newStringFromCharsMixedBegin`, I verified that performance remained consistent on x64. On aarch64, performance improved by 8% for size = 7, but decreased by 7% for size = 64. For detailed performance data, see the Markdown data in the draft pull request I submitted.https://github.com/openjdk/jdk/pull/26553#issuecomment-3138357748 - Shaojin Wen ------------------------------------------------------------------ 发件人：Roger Riggs <roger.ri...@oracle.com> 发送时间：2025年7月31日(周四) 03:17 收件人："core-libs-dev"<core-libs-dev@openjdk.org> 主 题：Re: Reuse the StringUTF16::putCharsSB method instead of the Intrinsic in the StringUTF16::toBytes Hi, Unsafe.uninitializedArray and StringConcatHelper.newArray was created for the exclusive use of StringConcatHelper and by HotSpot optimizations. Unsafe.uninitializedArray and StringConcatHelper.newArray area very sensitive APIs and should NOT be used anywhere except in StringConcatHelper and HotSpot. Regards, Roger On 7/30/25 11:40 AM, jaikiran....@oracle.com<mailto:jaikiran....@oracle.com> wrote: I'll let others knowledgeable in this area to comment and provide inputs to this proposal. I just want to say thank you for bringing up this discussion to the mailing list first, providing the necessary context and explanation and seeking feedback, before creating a JBS issue or a RFR PR. -Jaikiran On 30/07/25 7:48 pm, wenshao wrote: In the discussion of `8355177: Speed up StringBuilder::append(char[]) via Unsafe::copyMemory` (https://github.com/openjdk/jdk/pull/24773), @liach (Chen Liang) suggested reusing the StringUTF16::putCharsSB method introduced in PR #24773 instead of the Intrinsic implementation in the StringUTF16::toBytes method. Original: ```java @IntrinsicCandidate public static byte[] toBytes(char[] value, int off, int len) { byte[] val = newBytesFor(len); for (int i = 0; i < len; i++) { putChar(val, i, value[off]); off++; } return val; } ``` After: ```java public static byte[] toBytes(char[] value, int off, int len) { byte[] val = (byte[]) Unsafe.getUnsafe().allocateUninitializedArray(byte.class, newBytesLength(len)); putCharsSB(val, 0, value, off, off + len); return val; } ``` This replacement does not degrade performance. Running StringConstructor.newStringFromCharsMixedBegin verified that performance is consistent with the original on x64 and slightly improved on aarch64. The implementation after replacing the Intrinsic implementation removed 100 lines of C++ code, leaving only Java and Unsafe code, no Intrinsic or C++ code, which makes the code more maintainable. I've submitted a draft PR https://github.com/openjdk/jdk/pull/26553 , please give me some feedback. - Shaojin Wen
