Re: 回复：Reuse the StringUTF16::putCharsSB method instead of the Intrinsic in the StringUTF16::toBytes

[Chen Liang]

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-retn at openjdk.org> on behalf of wenshao <shaojin.wensj at alibaba-inc.com>
Sent: Wednesday, July 30, 2025 9:45 PM
To: Roger Riggs <roger.riggs at oracle.com>; core-libs-dev <core-libs-dev at 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.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), @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/20250731/c3a3bcd3/attachment-0001.htm>