[foreign-memaccess+abi] RFR: Remove mem barriers to allow loop optimizations for vectors accessing off-heap

[Paul Sandoz]

On Wed, 7 Jul 2021 23:30:39 GMT, Radoslaw Smogura <github.com+7535718+rsmogura at openjdk.org> wrote:

> This patch is to remove memory barriers, to allow better optimization of loops.
> 
> With mem barriers loops can't be optimized too much as code in compiler can not traverse loop back control through mem barriers to determine exit condition.
> 
> **Looking for feedback about possible impact.**
> 
> Partially discussed in, and extracted from https://mail.openjdk.java.net/pipermail/panama-dev/2021-June/014204.html
> 
> After
> 
> Benchmark                                       (size)  Mode  Cnt      Score      Error  Units
> VectorCopySegments.copyWithNative                 1024  avgt   10     20.293 ?    0.436  ns/op
> VectorCopySegments.copyWithNative              1048576  avgt   10  22270.840 ?  579.533  ns/op
> VectorCopySegments.copyWithNativeShared           1024  avgt   10     15.854 ?    0.061  ns/op
> VectorCopySegments.copyWithNativeShared        1048576  avgt   10  21948.236 ?   43.981  ns/op
> VectorCopySegments.copyWithNativeToArray          1024  avgt   10     20.318 ?    0.347  ns/op
> VectorCopySegments.copyWithNativeToArray       1048576  avgt   10  22142.499 ?  305.501  ns/op
> VectorCopySegments.copyWithVector                 1024  avgt   10     31.240 ?    0.333  ns/op
> VectorCopySegments.copyWithVector              1048576  avgt   10  25320.898 ?  118.397  ns/op
> VectorCopySegments.copyWithVectorDirectBuffer     1024  avgt   10     21.605 ?    0.210  ns/op
> VectorCopySegments.copyWithVectorDirectBuffer  1048576  avgt   10  23613.272 ? 1030.153  ns/op
> VectorCopySegments.copyWithVectorShared           1024  avgt   10     19.897 ?    0.485  ns/op
> VectorCopySegments.copyWithVectorShared        1048576  avgt   10  24719.767 ?  453.725  ns/op
> VectorCopySegments.copyWithVectorShuffle          1024  avgt   10     36.364 ?    0.669  ns/op
> VectorCopySegments.copyWithVectorShuffle       1048576  avgt   10  29730.528 ?  339.100  ns/op
> VectorCopySegments.copyWithVectorToArray          1024  avgt   10     29.282 ?    0.338  ns/op
> VectorCopySegments.copyWithVectorToArray       1048576  avgt   10  28502.004 ?  593.347  ns/op
> VectorCopySegments.copyWithVectorUnroller         1024  avgt   10     36.368 ?    0.092  ns/op
> VectorCopySegments.copyWithVectorUnroller      1048576  avgt   10  21528.433 ?  303.141  ns/op
> 
> 
> Before
> 
> Benchmark                                       (size)  Mode  Cnt      Score      Error  Units
> VectorCopySegments.copyWithVector                 1024  avgt   10     30.841 ?    0.119  ns/op
> VectorCopySegments.copyWithVector              1048576  avgt   10  44834.639 ?  746.965  ns/op
> VectorCopySegments.copyWithVectorShuffle          1024  avgt   10     47.797 ?    0.672  ns/op
> VectorCopySegments.copyWithVectorShuffle       1048576  avgt   10  61171.416 ? 5656.479  ns/op
> VectorCopySegments.copyWithVectorUnroller         1024  avgt   10     49.522 ?    1.027  ns/op
> VectorCopySegments.copyWithVectorUnroller      1048576  avgt   10  72145.653 ?  987.111  ns/op

VarHandle access will use unsafe, and go through the more sophisticated analysis (Vladimir linked to) to determine whether barriers are required.

You can follow the unsafe logic from here https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/library_call.cpp#L2212

We need to do something similar for vector load/store (just for plain accesses for now).

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

PR: https://git.openjdk.java.net/panama-foreign/pull/566