Unsafe vs MemorySegments / Bounds checking...

[Jorn Vernee]

FWIW, one more thing you could try is to mask off the sign bit from the 
address value before doing the access through VIRTUAL_MEMORY. You will 
still pay for the bitwise and, but it may be cheaper than the sign check.

Jorn

On 5-11-2024 19:11, Maurizio Cimadamore wrote:
> 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$ 
>>