Memory Segment efficient array handling

[Maurizio Cimadamore]

>> The reason why copying is slower for small segments is that, I think, my
>> benchmark iterations run in 4-5ns and, at these levels, you are
>> sensitive to the cost of the liveness checks. There's not a lot we can
>> do to eliminate that - it's the price of safety.
> OK that's true. But in my own Unsafe.copyMemory code wasn't doing MemorySegment.address().toRawLongValue() not also doing the liveness check?
True - so the liveness check probably that won't make a lot of 
difference in your case. But note that the bound checks are still 
applied in MemorySegment::copyMemory.
>
>> The good news is that in the case of heap segment wrappers, we know
>> exactly that the size is gonna fit inside an int (it's an array after
>> all!), so we can remove the check. If we remove the flag check, and just
>> set the segment to always be treated as "SMALL", we get the following
>> results:
> Is this really true? What about a huge long[] array, that could be (2^31-8 maximum index) * 8 bytesPerLong = 16 gigabytes? (or are those limited by the Java standard in maximum array size?)
in the PR I've submitted I only tweaked byte segment wrappers. We could 
resort to more complex internal representation for other heap segments, 
but I believe the true way forward is to wait for the long 
optimizations, and to completely remove the SMALL segment hacks.
>
> Sorry, I missed that class. I was opening the pull request and only looked at the red/green changes in MemorySegment. I missed the first class.
>
> The methods provided there exactly replace my three shapes in the code. And on top they allow to swap. Side note: MemoryCopy in the current PR has the swapping code commented out.
Yeah - Lee is working on that MemoryCopy class (and associated test). I 
have provided the "swappy" copyFrom overload in MemorySegment, I believe 
Lee will add support for that soon.
>
> Last question: why does https://bugs.openjdk.java.net/browse/JDK-8223051 not help for the integer vs. long loop variables? Does this not allow to remove the small vs. large segment distinction? I thought this change in hotspot was added to support long loops, if it is in fact "small".

My understanding is that the change has been split in multiple chunks. 
The chunk we mostly depend on is this:

https://bugs.openjdk.java.net/browse/JDK-8259609

(in fact I'm coordinating with Roland, the author of that work, and he's 
testing the patch against a version of panama which doesn't have 
workarounds for small segments).

I did run all Panama benchmarks after JDK-8223051 was pushed, and 
removed various workarounds, but  there was still a performance gap. 
Roland reassured me that the gap should disappear once JDK-8259609 is 
pushed.

Maurizio

>
> Uwe
>