Unsafe vs MemorySegments / Bounds checking...

[Brian S O'Neill]

On 2024-10-30 01:58 PM, Ron Pressler wrote:
> 
> 
>> On 30 Oct 2024, at 20:19, Brian S O'Neill <bronee at gmail.com> wrote:
>>
>> The problem is that the FFM API currently isn't a good enough replacement for the few remaining operations. It's close, though.
> 
> Another problem is that you have a very particular definition of “good enough” which is not the one we’re striving for. As Maurizio said, performance will improve, but identical performance to Unsafe in *every* case is not a goal (at least not currently).
> 

There's no fundamental reason why performance shouldn't be identical. 
With a reference to a MemorySegment with access to the entire address 
space, then it's effectively the same as the Unsafe class. (for memory 
access stuff only, not Java fields, etc.)

As can be seen so far, with a special VarHandle trick, the performance 
is in fact the same in many cases, but this is a fragile technique. At 
the very least, there needs to be a recommended alternative to the 
Unsafe class which offers good performance, but there isn't one. The 
VarHandle trick isn't intuitive, and it depends too much on the inliner. 
I don't particularly like the idea of all the "force inline" annotations 
which just seems like a workaround.

> 
> Are you proposing to add a new restricted unsafe API for the probably small and hopefully shrinking class of applications that would be significantly affected when moving from Unsafe to FFM? This sounds like a big ask for an unclear benefit. First we’ll need to see how big the problem is and if improvements to FFM can’t take care of nearly all of it (again, absolute parity with Unsafe in *every* conceivable case is not an important-enough goal).

I don't care how it's implemented. New API? Sure. Optimized when using 
the existing API? That's fine too. What I have right now with a 
VarHandle is a bit messy, and perhaps it should only be viewed as a 
temporary solution. If the more obvious technique against a 
MemorySegment can be optimized, then that's preferred.

> 
> As for the simplicity aspect, that’s subjective, the FFM API was iteratively designed and refined over years, and even if you find the result not to your taste, the overall amount of code directly interacting with either FFM or Unsafe (let alone the “new Unsafe”) is expected to be relatively small and well-encapsulated. You’re now talking about offering different APIs to suit the different tastes among what is a small group of developers to begin with.

I think my perception with respect to simplicity is with respect to the 
VarHandle trick, which wasn't something I came up with. It was 
recommended on this list by one of the FFM designers, so my 
interpretation is that this is the "correct" solution, when the 
straightforward approach that I tried wasn't very efficient.

My suggestion going forward: If someone is concerned with the 
performance of an API, when used in the way it was intended, don't 
recommend an oddball solution as a workaround, unless it's really 
intended to be temporary.


> 
>> The FFM API is mostly useless in that case, because foreign functions cannot be linked in anyhow.
> 
> That depends what is meant by “mostly”. There’s no doubt that FFI is a major aspect of FFM, but there’s useful stuff you can do with I/O without restricted methods.
> 
> — Ron