回复:Reuse the StringUTF16::putCharsSB method instead of the Intrinsic in the StringUTF16::toBytes
wenshao
shaojin.wensj at alibaba-inc.com
Thu Jul 31 02:45:55 UTC 2025
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 <https://github.com/openjdk/jdk/pull/26553#issuecomment-3138357748 >
-
Shaojin Wen
------------------------------------------------------------------
发件人:Roger Riggs <roger.riggs at oracle.com>
发送时间:2025年7月31日(周四) 03:17
收件人:"core-libs-dev"<core-libs-dev at 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.pai at oracle.com <mailto: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 <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 <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/20250731/bfbc7faf/attachment-0001.htm>
More information about the core-libs-dev
mailing list