On Tue, 10 Jun 2025 10:14:21 GMT, Johan Sjölen <jsjo...@openjdk.org> wrote:
>> What's wrong about `memcpy`, or rather the builtin version? Naturally I >> could write a for cycle copying the bytes, and rely on the compiler to >> optimize that out anyway, but I think that this makes the intention clear. >> >> If the handling was done through OS, I guess that the penalty would be >> actually quite severe. I could have tested the previous version on aarch64 >> e.g. in AWS, though now there's no casting of pointers anymore. >> >> When we have a final version, I could set up a build in AWS and report >> performance data from there. > >>What's wrong about memcpy, or rather the builtin version? > > Doesn't regular `memcpy` compile into the builtin anyway? Aren't there LE/BE > concerns when you do this type of computation? >From what I read `memcpy` should be treated as builtin but in debugger I've >seen deeper stacks. Anyway, this code is gone, I didn't really think about big endian archs. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2137489958
