Unsafe vs MemorySegments / Bounds checking...

[Brian S O'Neill]

On 2024-10-30 12:31 PM, Ron Pressler wrote:
> 
> 
>> On 30 Oct 2024, at 19:12, Brian S O'Neill <bronee at gmail.com> wrote:
>>
>>
>> The current approach is near to the Unsafe class in performance, but it doesn't offer any safety features. I can access an illegal address just as unsafely with the FFM API as I could before.
> 
> That’s incorrect. First, Unsafe could be used for on-heap manipulation of regular objects, which is much more troubling when it comes to which invariants can be trusted. Second, FFM separates out the unsafe aspects and allows controlling them per module so that you can localise which modules deserve greater scrutiny.
> 

There seems to be a misunderstanding here. The context of the discussion 
is only with respect to the low-level memory access operations of the 
Unsafe class, not the backdoor field accesses into regular Java objects. 
I'm not advocating for something that looks exactly like the Unsafe 
class. The problem is that the FFM API currently isn't a good enough 
replacement for the few remaining operations. It's close, though.


>> It's a double regression (performance and simplicity)
> 
> I think “simplicity” here is arguable given the offset calculations that Unsafe requires, but when it comes to performance the bar isn’t zero regressions in all cases, but rather whether a significant portion of programs is negatively affected in a significant way.
> 
>> in exchange for nothing.
> 
> There are few invariants that the runtime can trust if any one of the transitive dependencies of a Java program uses Unsafe. One transitive dependency globally ruins the trustworthiness of all of the program’s invariants whether the program knows about it (and approves it) or not, and whether or not the use of Unsafe actually significantly improves the application’s performance.

Again, I think there's a misunderstanding. There's the full Unsafe class 
as it exists today, and there's the FFM API which provides a useful 
subset of the those operations. I have no personal attachment to the 
Unsafe class. The FFM API provides all the features I need already, but 
just in a more complicated and inefficient fashion. There's nothing 
preventing it from improving while still retaining all the other checks 
that it has.

> 
> Even with the restricted APIs enabled, most invariants can still be trusted. If only a negligible of applications are intolerably affected and only a small portion are tolerably affected, I’d say that is a small price to pay in exchange for a whole lot, including, BTW, performance improvements thanks to new optimisations the runtime could perform when there are more invariants it can trust.

What do you mean by "restricted APIs enabled"? That restrictions are in 
place? The FFM API is mostly useless in that case, because foreign 
functions cannot be linked in anyhow.
  > — Ron
> 
>