Thank you! I will follow along in the bug. On Mon, Jul 21, 2025 at 8:02 AM Per-Ake Minborg <per-ake.minb...@oracle.com> wrote:
> Hi Liam! > > Thank you for your comments on MemorySegment::getString ! > > The intention was that the creation of the intermediate array should be > elided, but as you point out, that is (at least sometimes) not the case. > I've made an experimental patch where I've used > JavaLangAccess::uncheckedNewStringNoRepl in StringSupport which looks > promising: > > > Base: > ToJavaStringTest.panama_readString 5 avgt 30 13.559 ± 0.246 ns/op > ToJavaStringTest.panama_readString 20 avgt 30 67.047 ± 7.541 ns/op <- > Slow > ToJavaStringTest.panama_readString 100 avgt 30 28.092 ± 0.547 ns/op > ToJavaStringTest.panama_readString 200 avgt 30 37.679 ± 0.645 ns/op > ToJavaStringTest.panama_readString 451 avgt 30 64.544 ± 1.096 ns/op > > Experimental Patch: > ToJavaStringTest.panama_readString 5 avgt 30 8.847 ± 0.178 ns/op > ToJavaStringTest.panama_readString 20 avgt 30 20.332 ± 4.495 ns/op > ToJavaStringTest.panama_readString 100 avgt 30 21.808 ± 0.315 ns/op > ToJavaStringTest.panama_readString 200 avgt 30 28.711 ± 0.105 ns/op > ToJavaStringTest.panama_readString 451 avgt 30 51.806 ± 1.067 ns/op > > > So, this indicates that there are gains to be made here, although the > ultimate solution might be something else (such as improving inlining). I > have raised an issue for this > <https://bugs.openjdk.org/browse/JDK-8362893>. > > Thanks again for bringing this to the general knowledge. > > Best, > Per Minborg > Oracle Core Libraries > ------------------------------ > *From:* core-libs-dev <core-libs-dev-r...@openjdk.org> on behalf of Liam > Miller-Cushon <cus...@google.com> > *Sent:* Friday, July 18, 2025 7:26 PM > *To:* OpenJDK Core Libs Developers <core-libs-...@openjdk.java.net> > *Subject:* FFM - Optimizing string reads in MemorySegment > > Hi, > > I have a question about the performance of string reads in MemorySegment. > > There was some discussion about reading strings with known lengths > in JDK-8333843, and the outcome was to update the getString javadoc to > recommend: > > byte[] bytes = new byte[length]; > MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length); > return new String(bytes, charset); > > As I understand it that's as efficient as what MemorySegment#getString is > doing under the hood, the main difference with getString is that it's first > reading the length of a null-terminated string, but after that it just uses > MemorySegment.copy and calls the String constructor. > > Has avoiding the byte[] copy in the String constructor been considered? > > In theory it might be possible for the runtime to inline the String > constructor, see that the byte[] doesn't escape, and skip the copy. In > practice, based on some benchmarking my colleague Louis Wasserman was > doing, that doesn't seem to be happening. > > Would it make sense to consider using > JavaLangAccess#uncheckedNewStringNoRepl here to avoid having to copy the > byte[]? > > Thanks, > Liam >
