RFR(S): 8136473: failed: no mismatched stores, except on raw memory: StoreB StoreI

[Vladimir Kozlov]

On 9/16/15 10:23 AM, Roland Westrelin wrote:
> Thanks for looking at this, Vladimir.
>
>> Hmm, so you just relaxed the assert. You may need to fix EA too because it also checks for matching types(memory sizes).
>> I remember we had problem with RAW accesses back when jsr292 was implemented. So EA gave up on RAW access and marks allocations as escaping. Also may be superword/vectorization will be affected.
>>
>> In general it is very bad for C2 to have different memory on the same non-RAW memory.
>
> It already happens with vectorization. Do you see another solution (rather than relaxing the assert)? Putting a MemBarCPUOrder before and after the unaligned store?

MemBarCPUOrder are definitely will help and it is simplest solution but, I think, it is too drastic.
It affect control flow and other memory slices.
We can try to mark such memory accesses or/and mark objects which have such accesses (if it is possible) and prevent 
vectorization and scalarization for them only.  We should be able execute optimization on other memory slices then.

Thanks,
Vladimir

>
> Roland.
>
>>
>> Modify test to make array scalar replaceable and see. Also try vectorization.
>>
>> Thanks,
>> Vladimir
>>
>> On 9/16/15 1:35 AM, Roland Westrelin wrote:
>>> http://cr.openjdk.java.net/~roland/8136473/webrev.00/
>>>
>>> The problem here is that intrinsified Unsafe.Put*Unaligned methods may cause mismatched stores to be on the same memory slice.
>>>
>>> Roland.
>>>
>