Reuse the StringUTF16::putCharsSB method instead of the Intrinsic in the StringUTF16::toBytes

[jaikiran.pai at oracle.com]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250730/7d81297b/attachment.htm>