<div dir="ltr">Another idea I have just come up with:<div><br></div><div>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.</div><div><br></div><div>The disadvantage of the idea is that it removes one obstacle for library writers, which may make the unsafe accesses more attractive to them.</div><div><br></div><div>Regards,</div><div>Quan Anh</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 12 Jan 2024 at 22:14, Quân Anh Mai <<a href="mailto:anhmdq@gmail.com">anhmdq@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Please let me know if there is any misunderstanding regarding the situation, or if this is not the suitable mailing list for the proposal.</div><div><br></div><div>Regards,</div><div>Quan Anh</div></div>
</blockquote></div>