Unsafe vs MemorySegments / Bounds checking...

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Wed Oct 30 21:49:13 UTC 2024


On 30/10/2024 20:28, Brian S O'Neill wrote:
> The "smoking gun" actually has been identified. The call chain is too 
> large and inlining gives up. Things improve a bit when I can force 
> inlining, but I shouldn't have to do that.
Which method fails to inline? Is that a FFM method or a method in your 
library? How much do things improve when you force inlining? And, I 
assume this is with the var handle combinator approach?
> Should I just go back to square one and write the code in what looks 
> to be the most straightforward, and report the results? As I recall, 
> the performance regression was easier to spot even in a micro benchmark.

I think that might be a good idea. It would be good if we could isolate 
a part of your library where the regression is coming from -- while it's 
possible this is a "death by a thousand cuts" situation, it is typically 
not the case.

What I would like to do in the meantime is (when I have some cycles) to 
write a benchmark which tests memory segment in a loop with random 
access (e.g. using random offsets). And then evaluate the costs 
associated with the various approaches in isolation and see if anything 
pops up. I have a couple of ideas on how to possibly improve the story 
for the unbounded MAX_VALUE access -- but I'd like to see where we are 
w.r.t. random access in vanilla Java 24 first.

Cheers
Maurizio



More information about the panama-dev mailing list