<div dir="ltr"><div>I think that while your concern is perfectly valid, it seems not evident. Looking at other languages, even if they do not require the addition of startup flags, despite the existence of unsafe capabilities, there seems to be no evidence that developers over-exploit those features. It can be argued that current Unsafe support in Java also does not make people recklessly seek its support. While C++ is special because of its default being unchecked, Java has a long culture of using checked accesses. Last but not least, the most important aspect is readability, as going from arr[i] to Unsafe.getIntUnchecked(arr, i) imposes a considerable cognitive load. To conclude, it is unlikely that unsafe accesses will be recklessly used given all the hassles and warnings.<br></div><div><br></div><div>FYI, in my submission to 1brc, using Unsafe decreases the execution time from 3.25s to 2.57s on the test machine.</div><div><br></div><div>Best regards,</div><div>Quan Anh</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 13 Jan 2024 at 00:53, Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com" target="_blank">maurizio.cimadamore@oracle.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"><br>
On 12/01/2024 15:24, Quân Anh Mai wrote:<br>
> Your proposed solution still requires 2 checks, a lifetime check <br>
> (albeit it can be hoisted, but not across function calls) and a <br>
> positive index check, a workaround as you have proposed before is to <br>
> create a segment on the fly and depend on the compiler to eliminate <br>
> everything, the downside is that it is prone to the failure of <br>
> inlining those function, which may be counter-productive. Furthermore, <br>
> the most important downside is that all these tricks with <br>
> MemorySegment will not work with Java arrays, which I think are the <br>
> more common arguments of Unsafe methods.<br>
<br>
While I agree that in principle some checks are still there (as I said <br>
in my email), these strategies have been proven quite effective when <br>
working with random-access idioms.<br>
<br>
But I take your point that all these tricks are based on the assumption <br>
that you care about off-heap access.<br>
<br>
One possible idea I mused about in the past, was to expose special var <br>
handles (whose creation would be subject to --enable-native-access or <br>
similar mechanism, of course). The problem with doing things such as <br>
these, is that if we do them for well-intentioned use cases (such as the <br>
frequency trading application that wants to shave off up to the very <br>
last nanosecond), I think everybody else will get the message that "this <br>
is how we do it", and will start using unsafe access even when there's <br>
no real need to use it.<br>
<br>
Heck, looking at the results of the 1brc competition, your pure Java <br>
solution (no Unsafe, just FFM) ended up scoring quite high (3rd!) - at <br>
some point the question has to become: how much safety I'm willing to <br>
sacrifice to get an extra 1% ? I know that's a subjective decision, of <br>
course, but it's one that, as a community, we need to gripple with (as <br>
that has deep repercussions on the rest of the ecosystem).<br>
<br>
Maurizio<br>
<br>
<br>
<br>
</blockquote></div>