[vector]: RFR (XS): Small bug fixes

[Paul Sandoz]

> On Feb 26, 2018, at 5:04 PM, Lupusoru, Razvan A <razvan.a.lupusoru at intel.com> wrote:
> 
> Hi Vladimir,
> 
> I am not too familiar with what Unsafe.fullFence() ends up generating in terms of code. However, if it generates something like "mfence" instruction, it is undesirable. Ideally we want a scheduling barrier so that C2 will not move memory operations across the barrier but that has zero cost in terms of generated code. If it has a zero cost indeed, then the patch looks fine to me.
> 

It will generate something equivalent to mfence, ‘lock addl’ (see matches for MemBarVolatileNode and also OrderAccess::fence).

I thought this was just a temporary reprieve to avoid crashes until something better is worked out.

Paul.


> Thanks,
> Razvan
> 
> -----Original Message-----
> From: panama-dev [mailto:panama-dev-bounces at openjdk.java.net] On Behalf Of Paul Sandoz
> Sent: Monday, February 26, 2018 9:55 AM
> To: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
> Cc: panama-dev at openjdk.java.net
> Subject: Re: [vector]: RFR (XS): Small bug fixes
> 
> 
> 
>> On Feb 22, 2018, at 10:10 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>> 
>> http://cr.openjdk.java.net/~vlivanov/panama/vector.fixes.00/
>> 
>> src/hotspot/cpu/x86/x86.ad:
>> 
>> While testing the patch proposed by Al Miftah, I spotted a bug in some AD rules for NegVI: src and dst registers can be the same and pxor then overwrites input value.
>> 
>> 
>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorIntrinsics.java:
>> 
> 
> A reasonable compromise +1
> 
> Paul.
> 
>> Mixing vector & scalar memory accesses on a same memory type can be problematic in C2: alias analysis can't detect interference between accesses of different width. That's why aliasing between vector & scalar accesses can get unnoticed and lead to incorrect code being generated.
>> 
>> Established way to fix that is to put memory barriers in between (e.g., raw unsafe accesses are surrounded by barriers).
>> 
>> All scalar accesses happens in default implementations and have to fetch backing array first. That's where I decided to put the fence.
>> 
>> A better place would be in JVM during intrinsification of VI::maybeRebox() (it can take into account whether any vector accesses are performed before putting a barrier), but for now I decided to just put it on Java side using Unsafe.fullFence() to simplify the implementation.
>> 
>> I considered there's no need in another barrier after, because scalars accesses into backing array are followed by vector box allocation and it should isolate vector accesses happening later.
>> 
>> Thanks!
>> 
>> Best regards,
>> Vladimir Ivanov
>