Unsafe vs MemorySegments / Bounds checking...

[Maurizio Cimadamore]

On 29/10/2024 18:35, Brian S O'Neill wrote:
> If you recall, I did send you a reproducer, and you did verify the 
> regression. This is what led you to come up with a strategy to define 
> a derived VarHandle. This helped somewhat, but you observed the 
> inliner giving up when the code was embedded in a very large method. 
> JDK 23 appears to have introduced a regression that has made this worse.

You sent an initial benchmark containing a binary search which we looked 
into and provided some possible workarounds. Unfortunately the 
workaround that worked well the benchmark did not translate into the 
full application.

You then sent a second benchmark which was really containing more or 
less the whole project. I remember I could spot a bunch of places where 
some inlining failure occurred, but we never drew any conclusion on 
those observation alone, and we couldn't even reproduce reliably among 
ourselves.

If you have a better benchmark, or you can pin point the exact place 
where the inlining failure occurs that would help immensely. You can 
play around with CompileCommand and force inline for specific methods of 
your application. (perhaps after verifying that such methods are not 
inlined, which you can verify with -XX:+PrintInlining).

> Why is the inliner giving up? Is it because the VahHandle transform 
> introduced too many layers of indirection? What if the equivalent 
> VarHandle could be produced (or be built in) which skipped a few 
> steps? Would this allowing the inlining to proceed as expected? Is 
> there a better strategy?

We need more data to answer questions such as these.

Maurizio