Howto replicate failure of 8254790?

Vladimir Kozlov vladimir.kozlov at oracle.com
Tue Oct 20 17:01:12 UTC 2020


Yes, I saw it too but I was not sure because we never hit the issue with Unicode string index intrinsic.
An other thing is we see the failure only on MacOS.

I also want someone to decode asm dump I provided in bug to see actual instructions where it happened.

Vladimir K

On 10/19/20 5:38 PM, Viswanathan, Sandhya wrote:
> Hi Jason,
> 
> I think I found the problem looking at the error log from Vladimir Kozlov. In stringL_indexof_char() function, the following snippet is the cause of problem:
> 
> 2807   bind(FOUND_CHAR);
> 2808   if (UseAVX >= 2) {
> 2809     vpmovmskb(tmp, vec3);
> 2810   } else {
> 2811     pmovmskb(tmp, vec3);
> 2812   }
> 2813   bsfl(ch, tmp);
> 2814   addl(result, ch);                         <====   The problem is here
> 2815
> 2816   bind(FOUND_SEQ_CHAR);
> 2817   subptr(result, str1);
> 
> The line addl(result, ch) should have been addptr(result, ch).
> 
> The same problem exists in the Unicode string index of char intrinsic as well and need to be fixed.
> 
> Hope this helps.
> 
> Best Regards,
> Sandhya
> 
> -----Original Message-----
> From: hotspot-compiler-dev <hotspot-compiler-dev-retn at openjdk.java.net> On Behalf Of Vladimir Kozlov
> Sent: Thursday, October 15, 2020 3:59 PM
> To: Tatton, Jason <jptatton at amazon.com>; David Holmes <david.holmes at oracle.com>; hotspot-compiler-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
> Subject: Re: Howto replicate failure of 8254790?
> 
> Hi Jason,
> 
> I added surrounding instructions dump from hs_err file we have so you can reconstruct x86 assembler from it.
> 
> If you look on si_addr: 0x00000000e41d2718 which case memory map failure, it looks like R8 =0x00000007e41d2700 is an
> oop: [B with upper 32-bits zeroed. It seems uppers 32-bits of address were cut.
> 
> But I don't see it can happens in stringL_indexof_char() sub. You correctly used movptr() and addptr() instructions.
> 
> Vladimir K
> 
> On 10/15/20 2:10 PM, Tatton, Jason wrote:
>> Thanks Vladimir and David, I have access to a new macbook with an Intel i7-9750H (supports AVX2) so I will try on that.
>>
>> -----Original Message-----
>> From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
>> Sent: 15 October 2020 20:25
>> To: David Holmes <david.holmes at oracle.com>; Tatton, Jason
>> <jptatton at amazon.com>; hotspot-compiler-dev at openjdk.java.net;
>> core-libs-dev at openjdk.java.net
>> Subject: RE: [EXTERNAL] Howto replicate failure of 8254790?
>>
>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>>
>>
>>
>> Note, we have old Mac machines in our testing env:
>> cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1,
>> sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul,
>> bmi1, bmi2, rtm, adx, fma, vzeroupper, clflush, clflushopt
>>
>> Use -XX:UseAVX=2
>>
>> But I was not able reproduce failure on my Skylake Linux machine even with -XX:UseAVX=2. Maybe there are other factors on MacOS.
>>
>> Regards,
>> Vladimir K
>>
>> On 10/14/20 5:48 PM, David Holmes wrote:
>>> Hi Jason,
>>>
>>> On 15/10/2020 10:42 am, Tatton, Jason wrote:
>>>> Hi all,
>>>>
>>>>
>>>>
>>>> I am trying to replicate the failure of the tier2 test mentioned in
>>>> 8254790<https://bugs.openjdk.java.net/browse/JDK-8254790> but I am
>>>> only seeing it pass under an x86 linux machine. Are there any specific architectural constraints under which this test should be run in order to make it fail?
>>>
>>> It failed on a Mac, not Linux.
>>>
>>> Cheers,
>>> David
>>>
>>>>
>>>>
>>>> I am running the test via: make test TEST="test/jdk/javax/xml/crypto/dsig/GenerationTests.java"
>>>>
>>>>
>>>>
>>>> Note that I am running the test against master without the commit:
>>>> "8254792: Disable intrinsic StringLatin1.indexOf until 8254790 is fixed" which disables the intrinsic that is causing the test to fail.
>>>>
>>>>
>>>>
>>>> Thanks
>>>> --
>>>> Jason
>>>>


More information about the core-libs-dev mailing list