Unsafe vs MemorySegments / Bounds checking...

[Maurizio Cimadamore]

>
>>
>> Stepping back, the problem at hand is that there might be some 
>> simplifications we could do to make the call stack of memory access 
>> var handle simpler. Provided we can back up some of these intuitions 
>> with hard evidence, and that we can simplify the calls _without 
>> losing functionality_ sure, that all sounds great. (Although I don't 
>> think there's many low hanging fruit in there -- but I would be glad 
>> to be proven wrong of course!).
>
> Yes. The hard evidence is the fact that the best performance achieved 
> so far is by using an unintuitive VarHandle transform. The 
> straightforward approach of using a MemorySegment directly isn't as 
> efficient.

>
> You want more evidence? Other people are struggling with this and have 
> posted their concerns to the mailing list. As for myself, I've burned 
> away dozens of hours of my life trying resolve these issues. You've 
> spent time yourself chasing things down and proposed the VarHandle 
> transformation in the first place. It shouldn't be this way.

My definition of evidence is best summarized by other, more productive 
posts. So I'll point at them instead:

https://mail.openjdk.org/pipermail/panama-dev/2024-October/020702.html

https://mail.openjdk.org/pipermail/panama-dev/2024-October/020695.html

https://mail.openjdk.org/pipermail/panama-dev/2024-September/020643.html

In this case there is no "smoking gun" that links any of the mentioned 
inlining failures to the actual performance regression you are 
experiencing.They might be related - they might not be.

We have tried to be quite responsive here and elsewhere when new issues 
were presented to us. If the problem is well understood and there's 
something we can do about it, we typically tend to fix things quickly. 
Case in point:

https://git.openjdk.org/jdk/pull/21764

In this case, things are less clear and it will take more work to 
identify the "real" root cause of what you are seeing.

>
>>
>> What we will **not** do is split the FFM API in two parts - safe and 
>> unsafe. This is not just about var handles - that's only a piece of 
>> the story. There's bulk copy, and there's also Linker access. Once 
>> there's a blessed way to remove checks in one place, one can ask for 
>> ways to disable checks everywhere else.
>
> I'm not suggesting this. The FFM API already supports safe and unsafe 
> access, although it uses the term "restricted".

Well, once you have "more direct" memory access var handles, you might 
want "more direct" copy methods...

We have restricted API points - but a very limited number of them, to do 
things that cannot be done otherwise (such as retroactively attach 
spatial and temporal bounds on a raw memory segment obtained from native 
code). And we should keep it that way.

>
>>
>> IMHO the most maintainable solution for your code is to use a segment 
>> whose bound is Long.MAX_VALUE. That won't be _exactly_ like Unsafe 
>> (because of the sign check), but it will be pretty close -- and at 
>> least you won't have to maintain long chains of adapted var handle 
>> and cross your fingers that everything optimizes correctly everywhere 
>> (which I suspect will make inlining of the methods in your library a 
>> bit more predictable).
>
> I tried this originally and again just now, but the performance is 
> worse, by about 1.5x. The sign check cannot be the primary issue.

This is IMHO the main thing that needs to be investigated. I tend to 
agree that this strategy should perform better than it does today.

Maurizio