[vectorIntrinsics] RFR: Optimize mem barriers for ByteBuffer cases [v6]

[Radoslaw Smogura]

On Tue, 3 Aug 2021 19:19:23 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Hi all, I think that for this PR, I rather don't want to push more changes. It already stepped out from the original concern of optimizing mem-bars, to optimizing polluted cases.
>
>> Hi all, I think that for this PR, I rather don't want to push more changes. It already stepped out from the original concern of optimizing mem-bars, to optimizing polluted cases.
> 
> Yeah, I am inclined to dial back to focus this PR on just the non-polluted cases. 
> AFAICT I think we can get a set of minimal changes using casting and unsafe for accessing buffer state with no need to modify byte buffer code or branch on heao/direct. WDYT?
> 
> We can then expand later with further experiments for polluted cases, evaluating the costs and benefits.

Hi @PaulSandoz, thank you for your suggestions and please check a new revision.

The test `VectorMemoryAlias` will fail if barriers will be removed in C++ code (and we have as well drop changes in `X-ScopedMemoryAccess` to avoid null checks).

---

I'm checking as well another approach, which I came out with today.

The purpose of barriers is to "refresh" memory in case of mixed access. However what if in case of mixed access, we would do:
* for a store we could assign result of StoreVector to two slices raw, and byte[] in a memory merge node,
* for a load, we could consume the whole memory as input, instead of a single slice.

Do you think this makes sense?

[1] https://github.com/rsmogura/panama-vector/commits/merege-mem-instead-of-barier

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

PR: https://git.openjdk.java.net/panama-vector/pull/104