RFR: 8319111: Mismatched MemorySegment heap access is not consistently intrinsified [v4]

[Jatin Bhateja]

On Fri, 1 Dec 2023 21:28:14 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> Using byte type to write irrespective of memory segment type would work on little endian architectures but not on big endian architectures. On big endian the memory load/store should use the associated memory segment element type so a reinterpret node is needed as is done in non masked case. Alternatively at the minimum a check that the underlying architecture is little endian would be good to add for the masked intrinsic to succeed for the new cases. I think something like ((Endian::NATIVE == Endian::LITTLE) would do that.

I agree, limiting this for little endian.  BTW, reinterpretation nodes are already in place currently before store and after loads, but re-interpretation of vector value is different from architecture level byte swizzling before loading memory contents in vector.  On big-endian architectures if we load 64 bit memory (laid out as [Hi-Addr] 0,1,2,3,4,5,6,7 [Lo-Addr] bytes in memory) into two integers then in case1) first int should hold  3:0 bytes and second one 7:4 byte in strict sense, however, case2) one may also argue if we see long memory layout from an integer view, then first integer value should have 7:4 byte and second one 3:0 byte. These are mismatched segment accesses backed by primitive arrays but being loaded into a vector of different type hence an unsafe semantics of case2 should be applicable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16888#discussion_r1412751061