RFR: 8362893: Improve performance for MemorySegment::getString

Shaojin Wen swen at openjdk.org
Mon Jul 28 05:04:54 UTC 2025


On Sun, 27 Jul 2025 12:36:20 GMT, Philippe Marschall <duke at openjdk.org> wrote:

> Use `JavaLangAccess::uncheckedNewStringNoRepl` in `MemorySegment::getString` to avoid byte[] allocation in the String constructor.
> 
> Fall back to the old code in the case of malformed input to get replacement characters as per Javadoc API specification. The existing tests in `TestStringEncoding` seem sufficient to me.
> 
> I ran the tier1 test suite and it passes.
> 
> For performance analysis I ran.
> 
>     make test TEST="micro:org.openjdk.bench.java.lang.foreign.ToJavaStringTest" MICRO="OPTIONS=-prof gc"
> 
> on an AMD Ryzen 7 PRO 5750GE.
> 
> These are the formatted results, the current master is the line on top, this feature branch is the line below. We can see an improvement in throughput driven by a reduction in allocation.
> 
> 
> Benchmark                                              (size)  Mode  Cnt     Score    Error   Units
> 
> ToJavaStringTest.panama_readString                          5  avgt   30    18.996 ±  0.044   ns/op
> ToJavaStringTest.panama_readString                          5  avgt   30    13.851 ±  0.028   ns/op
> 
> ToJavaStringTest.panama_readString                         20  avgt   30    23.570 ±  0.050   ns/op
> ToJavaStringTest.panama_readString                         20  avgt   30    18.401 ±  0.069   ns/op
> 
> ToJavaStringTest.panama_readString                        100  avgt   30    32.094 ±  0.207   ns/op
> ToJavaStringTest.panama_readString                        100  avgt   30    24.427 ±  0.112   ns/op
> 
> ToJavaStringTest.panama_readString                        200  avgt   30    43.029 ±  0.185   ns/op
> ToJavaStringTest.panama_readString                        200  avgt   30    31.914 ±  0.064   ns/op
> 
> ToJavaStringTest.panama_readString                        451  avgt   30    81.145 ±  0.403   ns/op
> ToJavaStringTest.panama_readString                        451  avgt   30    58.975 ±  0.233   ns/op
> 
> ToJavaStringTest.panama_readString:gc.alloc.rate.norm       5  avgt   30    72.000 ±  0.001    B/op
> ToJavaStringTest.panama_readString:gc.alloc.rate.norm       5  avgt   30    48.000 ±  0.001    B/op
> 
> ToJavaStringTest.panama_readString:gc.alloc.rate.norm      20  avgt   30   104.000 ±  0.001    B/op
> ToJavaStringTest.panama_readString:gc.alloc.rate.norm      20  avgt   30    64.000 ±  0.001    B/op
> 
> ToJavaStringTest.panama_readString:gc.alloc.rate.norm     100  avgt   30   264.000 ±  0.001    B/op
> ToJavaStringTest.panama_readString:gc.alloc.rate.norm     100  avgt   30   144.000 ±  0.001    B/op
> 
> ToJavaStringTest.panama_readString:gc.alloc.rate.norm     200  avgt ...

This optimization is not only needed within the JDK core library, but also by developers of basic class libraries and applications. This should be done by the C2 optimizer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26493#issuecomment-3125494530


More information about the core-libs-dev mailing list