RFR: 8309502: RISC-V: String.indexOf intrinsic may produce misaligned memory loads [v4]

Andrew Haley aph at openjdk.org
Thu Jun 8 08:35:54 UTC 2023


On Thu, 8 Jun 2023 05:49:05 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> Please review this attempt to remove misaligned loads in String.indexOf intrinsic on RISC-V
>> 
>> Initialy found these misaligned loads when profiling finagle-http test from renaissance suite.
>> The majority of trp_lam events (about 66k per finagle-http round) came at line 706 (https://github.com/openjdk/jdk/pull/14320/files#diff-35eb1d2f1e2f0514dd46bd7fbad49ff2c87703d5a3041a6433956df00a3fe6e6L706)
>> The other two produced about 100 events combined.
>> Later I've found this can partially be reproduced with StringIndexOf.advancedWithMediumSub.
>> Numbers on hifive before and after applying the patch:
>> 
>> 
>> Benchmark                                                  Mode  Cnt       Score      Error  Units
>> StringIndexOf.advancedWithMediumSub                        avgt   25   47031.406 ±  144.005  ns/op
>> 
>> 
>> After:
>> 
>> Benchmark                                                 Mode  Cnt       Score     Error  Units
>> StringIndexOf.advancedWithMediumSub                       avgt   25    4256.830 ±  23.075  ns/op
>> 
>> 
>> Testing: tier1/tier2 is clean on hifive.
>
> Vladimir Kempik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix nits

I am very concerned about the increased complexity and maintenance burden caused by these unaligned access patches. While RISC-V is not a mainstream arch at this time, it may become one, and it that happens we'll need something reasonably maintainable.
Sprinkling '`if (AvoidUnalignedAccesses)`' all over the back end is disastrous for readability. I urge you to find a more abstract solution, for example by creating a memory access assembler class and subclassing it as appropriate with aligned and unaligned versions.

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

PR Comment: https://git.openjdk.org/jdk/pull/14320#issuecomment-1582139173


More information about the hotspot-compiler-dev mailing list