Reducing byte[] copies of MemorySegment.getString

[Per-Ake Minborg]

Hi Philippe and Maurizio,

Sure, I will take a look at this improvement suggestion. Thanks, Philippe, for the tip.

Best, Per Minborg
________________________________
From: Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
Sent: Friday, June 13, 2025 3:45 PM
To: Philippe Marschall <kustos at gmx.net>; panama-dev at openjdk.org <panama-dev at openjdk.org>; Per-Ake Minborg <per-ake.minborg at oracle.com>
Subject: Re: Reducing byte[] copies of MemorySegment.getString

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20250613/d4780cb5/attachment-0001.htm>