Unsafe vs MemorySegments / Bounds checking...

[Ron Pressler]

> 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.

> 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. 

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.

— Ron