RFR: 8269119: C2: Avoid redundant memory barriers in Unsafe.copyMemory0 intrinsic

[Roland Westrelin]

On Wed, 25 Aug 2021 22:17:05 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> `Unsafe::copyMemory0` intrinsic unconditionally inserts barriers arounds the call to `unsafe_arraycopy` stub.
> It is a conservative approach and barriers can be avoided in most common cases (similar to what is done for scalar unsafe accesses).
> 
> `Unsafe::copyMemory()` performs argument validation which limits inputs either
> to off-heap location (null + absolute address) or primitive on-heap array.
> 
> The only cases when barriers are still needed are:
>  * mixed accesses (`Object+offset`);
>  * mismatched access due to lack of type info on base oop (`Object:NotNull+offset`). 
> 
> Testing: hs-tier1 - hs-tier6

Why do we need membars at all? Isn't it sufficient if the runtime call to the stub consumes all memory as input and produces an entire new memory state as output that is (wide_in true and wide_out true in GraphKit::make_runtime_call()? Doesn't that guarantee no write can float below the call and no read can float above the call?

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

PR: https://git.openjdk.java.net/jdk/pull/5259