Official support for Unsafe proposal

[Quân Anh Mai]

Hi,

Thanks for your detailed arguments. I agree that there is little
justification for introducing an Unsafe API for this use case, and
developers deeming the bound checks as a significant slowdown can reach for
JDK internals using --add-exports/--add-opens.

However I don't think I'm too optimistic here. The fundamental difference
between critical downcalls and unsafe accesses are how much developers
understand them. While it is easy to comprehend the requirements of unsafe
accesses and the possible consequences of not conforming them, it is much
harder for people to understand what exactly a critical downcall is without
knowing about the downcall implementation, and even harder to fully imagine
the ramifications of violating its expectations. Case in point, although I
have never seen code in Go that accesses array elements in an unchecked
manner, I see people passing Go pointers to C and keep them there all the
time (which is illegal similar to how you cannot keep a heap segment
pointer across critical calls, although it works in Go just because the GC
happens to be non-moving).

Regarding C2, I believe there is so much a compiler can do regarding
eliminating bound checks. Of course, there are a lot of rooms for
improvement, such as a constraint elimination pass (JDK-8307768). But even
then a lot of cases are simply too hard. For example, a Brotli decompressor
implemented in Rust can achieve a 11% speedup simply by disabling bound
checks in its hot spot [1]

Best regards,
Quan Anh

[1]: https://dropbox.tech/infrastructure/lossless-compression-with-brotli

On Tue, 16 Jan 2024 at 18:12, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

>
> 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20240117/cdb07ce0/attachment.htm>