RFR: 8369564: Provide a MemorySegment API to read strings with known lengths [v12]

[Liam Miller-Cushon]

On Fri, 21 Nov 2025 14:57:37 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
>> 
>> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
>> 
>> 
>>     byte[] bytes = new byte[length];
>>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>>     return new String(bytes, charset);
>> 
>> 
>> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
>> 
>> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
>> 
>> Benchmark results:
>> 
>> 
>> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
>> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ± 0.401  ns/op
>> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ± 0.295  ns/op
>> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ± 0.419  ns/op
>> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ± 0.496  ns/op
>> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ± 1.528  ns/op
>> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ± 0.048  ns/op
>> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ± 0.125  ns/op
>> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ± 0.058  ns/op
>> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ± 0.089  ns/op
>> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ± 0.054  ns/op
>> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ± 0.046  ns/op
>> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ± 0.046  ns/op
>> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ± 0.187  ns/op
>> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ± 0.130  ns/op
>> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ± 0.227  ns/op
>> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ± 0.038  ns/op
>> ToJavaStringTest.panama_readStringLength      20...
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More javadoc updates

I'd like to suggest some additional changes:

I updated the warnings about truncated reads of strings containing `\0` to mention `MemorySegment#getString(long, Charset, long)` (see discussion here: https://github.com/openjdk/jdk/pull/28043#discussion_r2549972828)

I realized `StringSupport#copyBytes` was returning the wrong number of written bytes (`string.length()` vs. `numChars`), but also the return value wasn't being used anywhere.

I consolidated the copies of `copyBytes` in `StringSupport`. This means that for the case that doesn't need `srcIndex`/`numChars` there's a call to `String#substring`, but substring has a fast path to return the entire string, and I think that probably isn't worth micro-optimizing away.

I have tentatively updated the new `MemorySegment#copy` to return the number of bytes that were written. As we have discussed, the encoded length of a string isn't trivial to compute. Since `MemorySegment#copy` has to find out the length anyways, I think this is valuable information to return to the caller. The uses of the underlying `copyBytes` method in `StringSupport` are evidence of this, it needs to know the number of bytes written to write the null terminator at the correct position. Returning a length from the new copy method isn't consistent with existing overloads of `copy`, though. For many of those the number of bytes written is obvious, so although it's inconsistent I think it's defensible. What do you think?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28043#issuecomment-3569807201