Official support for Unsafe

[Quân Anh Mai]

Hi,

These days I have kept an eye on the 1brc challenge and 1 particular
phenomenon that has struck me is the usage of Unsafe by the participants.
While Java has developed a lot in terms of alternatives for Unsafe such as
VarHandle and FFM, a particular use case of Unsafe is to access memory in
an unsafe manner which cannot be done without some kind of unsafe support.

I believe that while the compiler can theoretically eliminate a lot of
bound checks and even if they exist, a predictable branch is normally
cheap, there will always be places where that is not the case, as the
access can be very far from the place where the compiler can get the
relevant information, or the bound checks will compete with the
bottlenecked CPU frontend or backend. In the cases where every nanosecond
counts, a bound check may be prohibitively expensive, and the capability to
bypass them would be valuable.

Looking at other languages, C++ is unsafe by nature, C#, Go and even Rust
all provide the ability to step out of the safe realm. As a result, I think
the necessity of unsafe accesses is evident.

Regarding the implementation, the support can start minimally with the
ability to access arrays or to interpret an array as another without bound
checking. Unsafe accesses require the program to start with
--enable-unsafe-accesses=<module-name>, the same as how we restrict native
accesses, which IMO exhibits a similar nature after the introduction of
passing heap segment to native downcalls. Last but not least, unsafe
accesses will still perform bound checks prior to C2 or in the presence of
a special unsafe flag, the former acts as a safety net that may catch most
mistakes the programmers make and the latter is a sanity check when the
need arises.

Please let me know if there is any misunderstanding regarding the
situation, or if this is not the suitable mailing list for the proposal.

Regards,
Quan Anh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240112/25ee62f0/attachment.htm>