<div dir="ltr"><div dir="ltr">On Tue, Jan 16, 2024 at 2:12 AM Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com">maurizio.cimadamore@oracle.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Rather than spending our precious cycle in developing (and than <br>
maintaining) fragile unsafe switch to make the code a bit faster here <br>
and there, I'd like for us to think of ways to think of safe ways to get <br>
to what we want? Is there some juice missing from C2? Does C2 need some <br>
help from the developer to understand the bounds of a certain access <br>
operation? What can an API do in order to help the JIT out in cases <br>
where performance fall off the cliff?<br></blockquote><div> </div><div>From my experience with using sun.misc.Unsafe in both Netty and Neo4j, I concur with this.</div><div>Bounds checks usually aren't performance sinks; poor decisions by the JIT is.</div><div>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.</div><div>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.</div><div>From this perspective, the jdk.internal.vm.annotation annotations are more interesting than another Unsafe.</div><div>One potential annotation that I'd like to see discussed would be for hinting inline targets.</div><div>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".</div><div><br></div><div>Cheers,</div><div>Chris</div></div></div>