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 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
