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

[Roger Riggs]

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