Reducing byte[] copies of MemorySegment.getString

[Maurizio Cimadamore]

Hi Philippe,
this is an interesting suggestion. As you observed, we already use JDK 
internals in String support, most notably to reduce a double allocation 
when _writing_ a string off-heap (where we get access to the string 
byte[] directly, instead of going through an intermediate array with 
String::getBytes). So your proposed patch completes that for reads too, 
which is nice, and will provide a decent boost in what is a relatively 
common use case.

I also think your handling of CharacterCodingException seems pragmatic.

@Per, can you take a look?

Thanks for sharing
Maurizio


On 13/06/2025 13:55, Philippe Marschall wrote:
> Hello
>
> I had a look at the implementation of MemorySegment.getString and it 
> seems to allocate every byte[] once in StringSupport and then a copy 
> in the String constructor. StringSupport already has access to 
> JavaLangAccess and therefore uncheckedNewStringNoRepl which can 
> allocate a String without copying the given byte[].
>
> I did an experiment and changed the StringSupport implementation to 
> call uncheckedNewStringNoRepl instead [1]. uncheckedNewStringNoRepl 
> behaves different from new String() and throws 
> CharacterCodingException on malformed input. The API contract of 
> MemorySegment#getString specifies replacement characters in case of 
> malformed input. The easiest way I found to support this is simply 
> catch and call the String constructor for malformed input.
>
> There is already an existing JMH microbenchmark for 
> MemorySegment#getString in ToJavaStringTest, I ran it with the GC 
> profiler (MICRO="OPTIONS=-prof gc"). And the results are as follows:
>
> - the average time per op goes down by about 25% to 30% depending on 
> the String size
> - allocations per op goes down by 33% to 50% depending on the String 
> size, the the relative savings increasing with the String size
>
> I ran the tier1 test suite and it passed.
>
>  [1] 
> https://github.com/marschall/jdk/commit/b43920dd7b666c5d09c088a9918c3d65a5a32e8c
>
> Cheers
> Philippe