Official support for Unsafe proposal

[Maurizio Cimadamore]

On 16/01/2024 04:35, David Holmes wrote:
> Putting something public in java.lang is the strongest endorsement of 
> an API and at says this API is intended for general use. 

Even worse, introducing language support for unsafe blocks, so that 
array access syntax can remain unchanged (as you stated in an earlier 
proposal).

The risk with all these things is to create flags, modes, APIs and 
language feature whose sole justification is to make another, existing 
API/language feature faster (at the expense of safety). That is a very 
thin justification for adding a new API/feature. The risk is you end up 
with two very similarly looking APIs (e.g. MemorySegment vs. 
UncheckedMemorySegment), with poor understanding on who should use 
which. And, I think you are a little too optimistic - when given a new 
hammer developers will try to find new nails (whether real or imagined). 
Case in point: look at the discussions over the Linker::critical option. 
There are some (few) cases where disabling native transition could make 
sense (esp. if you care about the last nanosecond spent in a native 
call) - but such concerns are typically immaterial for the 99.99% of the 
developers. And yet, no matter how we try and specify the javadoc for 
that linker option, I believe many developers will just reach for it as 
some kind of "make me fast" kind of switch, whether they really need it 
or not. But at least in that case the option is buried enough, and in an 
API which is already quite low-level and not 100% safe :-)

(For the records, were it not for the existence - and deprecation [1] - 
of the critical JNI mechanism we would probably NOT have added trivial 
support to Panama downcalls. That goes to show that once something gets 
in, even in the form of an unsupported flag, as critical JNI, it is very 
hard, or impossible for us to fully get rid of!)

Rather than spending our precious cycle in developing (and than 
maintaining) fragile unsafe switch to make the code a bit faster here 
and there, I'd like for us to think of ways to think of safe ways to get 
to what we want? Is there some juice missing from C2? Does C2 need some 
help from the developer to understand the bounds of a certain access 
operation? What can an API do in order to help the JIT out in cases 
where performance fall off the cliff?

Cheers
Maurizio

[1] - https://mail.openjdk.org/pipermail/panama-dev/2022-June/017074.html