[16] RFR (S) 8249749: modify a primitive array through a stream and a for cycle causes jre crash

[Vladimir Kozlov]

I reproduced it with -XX:UseAVX=0.

I will file bug and take care of it.

Thanks,
Vladimir K

On 8/18/20 2:57 PM, Vladimir Kozlov wrote:
> Thank you for reporting, Martin
> 
> Please, file bug and specify JDK version, VM flags and CPUID features on machine where it fail.
> 
> We test on x86 and aarch64 and I did not see any issues so far.
> 
> Regards,
> Vladimir
> 
> On 8/18/20 2:25 PM, Doerr, Martin wrote:
>> Hi Vladimir,
>>
>> we are hitting the following assertion after this change was pushed:
>> assert(my_pack(s) == __null) failed: only in one pack
>>
>> Stack:
>> V  [jvm.dll+0xbbac55]  SuperWord::construct_my_pack_map+0x135  (superword.cpp:1723)
>> V  [jvm.dll+0xbb57f7]  SuperWord::SLP_extract+0x427  (superword.cpp:520)
>> V  [jvm.dll+0xbcba0b]  SuperWord::transform_loop+0x48b  (superword.cpp:170)
>> V  [jvm.dll+0x895a09]  PhaseIdealLoop::build_and_optimize+0xef9  (loopnode.cpp:3270)
>> V  [jvm.dll+0x3df4b6]  Compile::Optimize+0xf76  (compile.cpp:2187)
>> ...
>>
>> Seems to be reproducible by JTREG test compiler/vectorization/TestComplexAddrExpr.java on some x64 and aarch64 machines.
>> (May depend on CPU model.)
>>
>> Is this a known issue?
>> Or should I open a bug?
>>
>> Best regards,
>> Martin
>>
>>
>>> -----Original Message-----
>>> From: hotspot-compiler-dev <hotspot-compiler-dev-
>>> retn at openjdk.java.net> On Behalf Of Vladimir Kozlov
>>> Sent: Montag, 10. August 2020 19:03
>>> To: hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
>>> Subject: Re: [16] RFR (S) 8249749: modify a primitive array through a stream
>>> and a for cycle causes jre crash
>>>
>>> Thank you, Vladimir
>>>
>>> Vladimir K
>>>
>>> On 8/10/20 2:04 AM, Vladimir Ivanov wrote:
>>>>
>>>>> http://cr.openjdk.java.net/~kvn/8249749/webrev.00/
>>>>
>>>> Looks good.
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8249749
>>>>>
>>>>> SuperWord does not recognize array indexing pattern used in the test
>>> due to additional AddI node:
>>>>>
>>>>> AddI(AddI(Invariant(j*n), Loop_phi(i)), Loop_inc(1))
>>>>>
>>>>> As result it can't find memory reference to align vectors. But code ignores
>>> that and continue execution.
>>>>> Later when align_to_ref is referenced we hit SEGV because it is NULL.
>>>>>
>>>>> The fix is to check align_to_ref for NULL early and bailout.
>>>>>
>>>>> I also adjusted code in SWPointer::scaled_iv_plus_offset() to recognize
>>> this address pattern to vectorize test's code.
>>>>> And added missing _invar setting.
>>>>>
>>>>> And I slightly modified tracking code to investigate this issue.
>>>>>
>>>>> Added new test to check some complex address expressions similar to
>>> bug's test case. Not all cases in test are
>>>>> vectorized - there are other conditions which prevent that.
>>>>>
>>>>> Tested tier1,tier2,hs-tier3,precheckin-comp
>>>>>
>>>>> Thanks,
>>>>> Vladimir K