Unsafe vs MemorySegments / Bounds checking...

[Maurizio Cimadamore]

IMHO this is why the approach with "VIRTUAL_MEMORY" in the end is the 
more robust of the two, because it leads to far simpler code, and it is 
much less sensitive to what the inliner decides to do on Tuesdays.

We got at the "reinterpret-on-the-fly" solution honestly: it was the 
only way to fully eliminate the bound check. But, with the PR I 
mentioned, now the only thing that separates VIRTUAL_MEMORY from the 
other approach is the cost of a sign check (in the worse case where JIT 
can't speculate on the sign). That seems like a better compromise, at 
least on paper -- although we'll need to see how that works out in 
practice (after the PR is integrated).

Maurizio




On 05/11/2024 17:58, Ioannis Tsakpinis wrote:
>> Interesting find. If you forceInline that (e.g. using CompileCommand) does it get better?
> No, inlining still fails. Afaict, the relevant code is in
> InlineTree:try_to_inline [1] and it looks like the maximum inline level
> violation is overriding any inlining decision done before it, including
> the forced inlining via CompileCommand.
>
> [1]:
> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/3fab8e37bbebbb3930108b2015efe488b1fa1e97/src/hotspot/share/opto/bytecodeInfo.cpp*L364__;Iw!!ACWV5N9M2RV99hQ!JGSoz-WxXvX6mhZyZMC9dpr9DyQ6ij8VfSQ7xX_ZJJen332DRnxNcq5AIrUBoK9YYC0Trlr7JcD_hKRxEo9MtOw$