RFR: 8287289: Gather/Scatter with Index Vector [v3]

[Paul Sandoz]

On Tue, 11 Apr 2023 18:19:34 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> * have tried adding operations on `MemorySegment` but encountered failures possibly due to mismatched element types. I have not taken a closer look but notably currently our loads/stores with respect to `MemorySegment` only work on native segments of heap segments backed by byte arrays.
> 

Ah, now i recall being extra conservative because at the time the alignment constraints of heap-backed segments were also conservative (and the specification was somewhat of a moving target). It's much more flexible now, so it's possible to _scribble_ on any kind of heap-backed segment with unaligned access for values of a different size to the element size.

In ScopedMemoryAccess there is this:

        // @@@ Smarter alignment checking if accessing heap segment backing non-byte[] array
        if (msp.maxAlignMask() > 1) {
            throw new IllegalArgumentException();
        }


So i think we can remove this limitation, removing the exception from the segment access JavaDoc and tweaking the doc to use `ValueLayout.JAVA_E_UNALIGNED` rather than `ValueLayout.JAVA_E.withBitAlignment(8)`

And, if needed, tweak the HotSpot internals to deal with the element mismatch.


> * It turns out that adding an offset complicates the range check quite a lot as we have to take into consideration overflow of addition/subtraction. The users can easily simulate this operation by adding/subtracting from the index vector, albeit without the guarantees in cases of overflow, but I think in reality application code does not require such strong guarantees as the JDK itself, maybe a separate helper method to perform strict range checks would be desirable.

Agreed, there is flexibility in allowing the user to control the offset calculation.

-------------

PR Comment: https://git.openjdk.org/panama-vector/pull/213#issuecomment-1503956954