Official support for Unsafe

[Quân Anh Mai]

Another idea I have just come up with:

Without the flag the program still runs as normal with the checks intact,
and in the presence of --enable-unsafe-access, C2 will remove the bound
checks away. This has advantages that it allows libraries to not force
usage of the flag on the program and the program can consciously choose to
remove the checks if the need arises. For example, multiple libraries used
by a program all of which can be used in performance-sensitive situations
such as json parsing libraries, but from the perspective of the program,
only 1 of them truly needs to be optimal, or even none of them need to be.
This approach allows the program to keep most checks intact and is only
exposed to minimal risk if the flag is added.

The disadvantage of the idea is that it removes one obstacle for library
writers, which may make the unsafe accesses more attractive to them.

Regards,
Quan Anh

On Fri, 12 Jan 2024 at 22:14, Quân Anh Mai <anhmdq at gmail.com> wrote:

> 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/20240113/c91a5a18/attachment.htm>