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

[Paul Sandoz]

On Sat, 31 Jul 2021 12:32:16 GMT, Radoslaw Smogura <github.com+7535718+rsmogura at openjdk.org> wrote:

>> # Description
>> This change tries to remove mem bars for byte buffer cases.
>> 
>> Previously mem bars were inserted almost unconditionally if attemp to native memory acees where detected. This patch tries to follow up inline_unsafe_access and insert bar only if can't determine if it's heap or off-heap (type missmatch cases are not ported).
>> 
>> # Testing
>> Memory tests should include rollbacking JDK changes, and leaving only hotspot, as intrinsics should be well guarded
>> 
>> # Notes
>> Polluted cases to be addressed later
>> 
>> # Benchmarks
>> 
>> Benchmark                                (size)  Mode  Cnt    Score   Error  Units
>> ByteBufferVectorAccess.arrays              1024  avgt   10   12.585 ? 0.409  ns/op
>> ByteBufferVectorAccess.directBuffers       1024  avgt   10   19.962 ? 0.080  ns/op
>> ByteBufferVectorAccess.heapBuffers         1024  avgt   10   15.878 ? 0.187  ns/op
>> ByteBufferVectorAccess.pollutedBuffers2    1024  avgt   10  123.702 ? 0.723  ns/op
>> ByteBufferVectorAccess.pollutedBuffers3    1024  avgt   10  223.928 ? 1.906  ns/op
>> 
>> Before
>> 
>> Benchmark                                (size)  Mode  Cnt    Score   Error  Units
>> ByteBufferVectorAccess.arrays              1024  avgt   10   14.730 ? 0.061  ns/op
>> ByteBufferVectorAccess.directBuffers       1024  avgt   10   77.707 ? 4.867  ns/op
>> ByteBufferVectorAccess.heapBuffers         1024  avgt   10   76.530 ? 1.076  ns/op
>> ByteBufferVectorAccess.pollutedBuffers2    1024  avgt   10  143.331 ? 1.096  ns/op
>> ByteBufferVectorAccess.pollutedBuffers3    1024  avgt   10  286.645 ? 3.444  ns/op
>
> Radoslaw Smogura has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - White space fix
>  - Remove buffer checks in ScopedMemoryAccess
>    
>    This checks right now do not bring anything useful (right now),
>    performance issues has to be addressd in different way.
>  - Refactor: use library access checks
>    
>    - extract access /decorators checks from library_call
>    - re-use extracted code to build fencing for vectors

What if we use unsafe to read the BB read only field? we do that for VHs:

        @ForceInline
        static int indexRO(ByteBuffer bb, int index) {
            if (UNSAFE.getBoolean(bb, BYTE_BUFFER_IS_READ_ONLY))
                throw new ReadOnlyBufferException();
            return index(bb, index);
        }

The virtual method call to `Buffer.isReadOnly` might be complicating matters.

Logistically, having seen the scope of changes, perhaps it's best to first focus on a smaller changeset for the specific problem, then revisit with better use of the decorators? That way we could integrate this PR to `vectorIntrinsics` then bring into `jdk`  then afterwards decide on a refactor, with input from the hotspot reviewers?

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

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