Unsafe vs MemorySegments / Bounds checking...

[Maurizio Cimadamore]

Hi Ioannis,
thanks for the extended test. I like your approach to test for inlining 
depth. See some comments below:

On 05/11/2024 00:42, Ioannis Tsakpinis wrote:
> Hey all,
>
> I've written a simple benchmark to explore the issues discussed in this
> thread and maybe quantify the relevant sources of overhead compared to
> equivalent memory access via Unsafe.
>
> https://urldefense.com/v3/__https://gist.github.com/Spasi/b5de16a30bd9d12436c6bad6cfc3f742__;!!ACWV5N9M2RV99hQ!Igyto45R0_LlP2hksyCIDMWRgrqTVVS3eMTJxocQKoajiQg3sP7NntQkvqmwNLTPvVZdpm6x5zFE8ZxriGfU1dg$
>
> My findings:
>
> 1. The alignment check appears to be just as (if not more) expensive
>     than bounds checking.
The alignment check can be disabled, by using a layout that is not 
aligned (e.g. JAVA_LONG_UNALIGNED - you seem to be using that here?).
> 2. The VarHandle / new-segment-per-access trick indeed works great when
>     EA scalar replacement succeeds. All checks are eliminated and the
>     entire memory address space is available.
Yes. As you note, how well this work depends on ability to scalar 
replace. Which depends on inlining.
> 3. The Scope::isAlive check is almost always hidden in the noise, but
>     it does become noticable for single accesses or small loops (set a
>     small offsetCount to test). I believe the fix for this is simple:
>     add an override to the GlobalSession class that always returns true.

It's a bit more complex than that, as that code really likes having a 
single implementation for all the liveness checks - otherwise you get 
bad profile pollution when multiple session kinds are involved. We're 
working on a solution:

https://git.openjdk.org/jdk/pull/21810

> I also tested how VarHandle access behaves in deeply nested code and
> I'm not seeing any evidence that VHs & MHs have extended inlining
> budgets or any kind of special "inlining bubble/horizon" within which
> EA is guaranteed to scalar-replace allocations.

I will leave this topic to those more knowledgeable (Vlad, Jorn?)

Maurizio