RFR(S): 8136473: failed: no mismatched stores, except on raw memory: StoreB StoreI
vladimir.kozlov at oracle.com
Wed Sep 16 17:48:09 UTC 2015
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.
>> Modify test to make array scalar replaceable and see. Also try vectorization.
>> On 9/16/15 1:35 AM, Roland Westrelin wrote:
>>> The problem here is that intrinsified Unsafe.Put*Unaligned methods may cause mismatched stores to be on the same memory slice.
More information about the hotspot-compiler-dev