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