[External] : Re: MemorySegment APIs for reading and writing strings with known lengths

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Wed Nov 19 10:00:50 UTC 2025


On 19/11/2025 08:35, Liam Miller-Cushon wrote:
> Thanks Jorn, I took another pass over the PR and have a draft of the 
> changes you described: https://github.com/openjdk/jdk/pull/28043 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/28043__;!!ACWV5N9M2RV99hQ!LQ7S1ywQkPUR1HoloUuVqfMjlWNYy-pQfvF30QR2JcA47rfuO3DUYfk1y3AP6-KQ0p_OnW2Rdi9ReHM8y16tGA$>
>
>         void copy(String src, Charset dstEncoding, int srcIndex,
>     MemorySegment dst, int numChars);
>
> For copy, many of the other overloads have a dstOffset as well. I 
> suppose another overload could be added for it later, or do we not 
> want that here?
You are right, we need a (destination) offset parameter as well.
>
>     For encoding directly into a memory segment without the need to go
>     to an intermediate buffer, it looks like we can use the internal
>     StringCharBuffer class, in combination with the
>     `CharsetEncoder::encode` method. But of course we can skip
>     encoding altogether when the internal string encoding matches the
>     target, and just do a bulk copy.
>
> Thanks, I got it working with StringCharBuffer/CharsetEncoder::encode 
> and did some initial benchmarking. It is nice that it avoids the copy, 
> but the benchmarking suggests it's ~4x slower than calling 
> String#getBytes. I wonder if it makes sense to use String#getBytes for 
> now, and consider future work to support encoding with substrings 
> directly to the destination with equivalent or better performance than 
> getBytes. What do you think?

 From some discussion offline, while the charset encoder API is nice and 
abstract, is not always the most optimal. Your mileage probably vary 
based on the length of the string to be encoded. I think for now using 
getBytes (+ having a trick to avoid that if the charset is compatible) 
should be good enough.

Maurizio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20251119/256f894c/attachment-0001.htm>


More information about the panama-dev mailing list