Unsafe vs MemorySegments / Bounds checking...

[Brian S O'Neill]

Even when all the inlining transformations work, it's still expensive 
because the compiler has to do a bunch of extra work. And when the 
calling method needs to get recompiled (as it often does), all the 
inlining transforms need to be done all over again.

In the end, the code (hopefully) gets transformed down into the original 
Unsafe method calls that would have been written instead. A set of more 
direct VarHandles might help, which could perform the basic low-level 
accesses and copies that the Unsafe class provides.

The current trick of transforming the VarHandle provided by the 
ValueLayout class is a hack. It only (mostly) works for reasons that are 
known to the FFM implementers. When I try other tricks with VarHandles 
and MemorySegments, it either doesn't work as well or the performance is 
substantially worse. The current hack is also extremely fragile, as 
evidenced by the JDK 23 regression.


On 2024-10-30 10:07 AM, Johannes Lichtenberger wrote:
> Also the discussions are always   very Hotspot specific, so in general 
> I've had better overall performance with the GraalVM JIT for my stuff, 
> but it may lack behind in optimizations for the Foreign Function and 
> Memory API and maybe the Vector API stuff, but I'm not sure if that's 
> still true, though
> 
> 
> Quân Anh Mai <anhmdq at gmail.com <mailto:anhmdq at gmail.com>> schrieb am 
> Mi., 30. Okt. 2024, 17:53:
> 
>     I agree that the implementations of the MemorySegment accessors are
>     overly complicated for such a performance-sensitive component. It
>     seems we can and should can simplify them massively.
>