Official support for Unsafe proposal

[Chris Vest]

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

> 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?
>

>From my experience with using sun.misc.Unsafe in both Netty and Neo4j, I
concur with this.
Bounds checks usually aren't performance sinks; poor decisions by the JIT
is.
Or rather, run-to-run variability in JIT decisions. If the JIT is
consistent in its decisions on some code, then you can change the code to
influence it.
But hot code often comes in groups of methods that call each other, and the
choice of which one to inline the others into can have a huge impact on
system performance.
>From this perspective, the jdk.internal.vm.annotation annotations are more
interesting than another Unsafe.
One potential annotation that I'd like to see discussed would be for
hinting inline targets.
As opposed to ForceInline which says "this should most likely be collapsed
down the call stack", I'd be interested in one that says "this one might be
a good place for those inlines to land".

Cheers,
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20240116/deb4e55e/attachment.htm>