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

[Vladimir Kozlov]

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