Official support for Unsafe

[Maurizio Cimadamore]

On 12/01/2024 15:24, Quân Anh Mai wrote:
> Your proposed solution still requires 2 checks, a lifetime check 
> (albeit it can be hoisted, but not across function calls) and a 
> positive index check, a workaround as you have proposed before is to 
> create a segment on the fly and depend on the compiler to eliminate 
> everything, the downside is that it is prone to the failure of 
> inlining those function, which may be counter-productive. Furthermore, 
> the most important downside is that all these tricks with 
> MemorySegment will not work with Java arrays, which I think are the 
> more common arguments of Unsafe methods.

While I agree that in principle some checks are still there (as I said 
in my email), these strategies have been proven quite effective when 
working with random-access idioms.

But I take your point that all these tricks are based on the assumption 
that you care about off-heap access.

One possible idea I mused about in the past, was to expose special var 
handles (whose creation would be subject to --enable-native-access or 
similar mechanism, of course). The problem with doing things such as 
these, is that if we do them for well-intentioned use cases (such as the 
frequency trading application that wants to shave off up to the very 
last nanosecond), I think everybody else will get the message that "this 
is how we do it", and will start using unsafe access even when there's 
no real need to use it.

Heck, looking at the results of the 1brc competition, your pure Java 
solution (no Unsafe, just FFM) ended up scoring quite high (3rd!) - at 
some point the question has to become: how much safety I'm willing to 
sacrifice to get an extra 1% ? I know that's a subjective decision, of 
course, but it's one that, as a community, we need to gripple with (as 
that has deep repercussions on the rest of the ecosystem).

Maurizio