Vector API: stack overflow on Big Endian

Paul Sandoz paul.sandoz at oracle.com
Thu Oct 22 18:11:11 UTC 2020


Hi Martin,

Can you provide more details on what test methods are failing?

I would like to know the scope of the test failures and more precisely where they occur.

My suspicion is there by be a problem with the test, specifically with the method castByteArrayData.

Paul.

> On Oct 22, 2020, at 6:23 AM, Doerr, Martin <martin.doerr at sap.com> wrote:
> 
> Hi Paul,
> 
> thanks a lot for your help. Your fix is working fine.
> 
> With that, I can only see one test failing:
> VectorReshapeTests
> 
> Failing with Species[byte, 16, S_128_BIT]->Species[short, 8, S_128_BIT] (lanewise), partLimit=2, block=8, part=0, origin=0
> Failing with Species[byte, 32, S_256_BIT]->Species[short, 16, S_256_BIT] (lanewise), partLimit=2, block=16, part=0, origin=0
> Failing with Species[byte, 64, S_512_BIT]->Species[short, 32, S_512_BIT] (lanewise), partLimit=2, block=32, part=0, origin=0
> Failing with Species[byte, 8, S_64_BIT]->Species[short, 4, S_64_BIT] (lanewise), partLimit=2, block=4, part=0, origin=0
> Failing with Species[byte, 8, S_Max_BIT]->Species[short, 4, S_Max_BIT] (lanewise), partLimit=2, block=4, part=0, origin=0
> 
> All of them fail because pairs are swapped like this:
> expect: [1, 0, 2, 0, 3, 0, 4, 0, 5, 0, 6, 0, 7, 0, 8, 0]
> output: [0, 1, 0, 2, 0, 3, 0, 4, 0, 5, 0, 6, 0, 7, 0, 8]
> 
> Do you know if that's another endianness problem?
> 
> Best regards,
> Martin
> 
> 
>> -----Original Message-----
>> From: Paul Sandoz <paul.sandoz at oracle.com>
>> Sent: Donnerstag, 22. Oktober 2020 02:27
>> To: Doerr, Martin <martin.doerr at sap.com>
>> Cc: hotspot-compiler-dev at openjdk.java.net
>> Subject: Re: Vector API: stack overflow on Big Endian
>> 
>> Hi Martin,
>> 
>> We definitely have far less exposure by default to BE platforms now that
>> SPARC is not a thing, it's easy to unintentionally hardcode a bias to LE.
>> 
>> Would it be possible to try running the tests on your BE platforms with the
>> following modification?
>> 
>> ---
>> a/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVect
>> or.java
>> +++
>> b/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVect
>> or.java
>> @@ -500,7 +500,7 @@ abstract class AbstractVector<E> extends Vector<E> {
>>     final <F>
>>     AbstractVector<F> defaultReinterpret(AbstractSpecies<F> rsp) {
>>         int blen = Math.max(this.bitSize(), rsp.vectorBitSize()) / Byte.SIZE;
>> -        ByteOrder bo = ByteOrder.LITTLE_ENDIAN;
>> +        ByteOrder bo = ByteOrder.nativeOrder();//LITTLE_ENDIAN;
>>         ByteBuffer bb = ByteBuffer.allocate(blen);
>>         this.intoByteBuffer(bb, 0, bo);
>>         VectorMask<F> m = rsp.maskAll(true);
>> 
>> Paul.
>> 
>> 
>>> On Oct 21, 2020, at 4:10 AM, Doerr, Martin <martin.doerr at sap.com>
>> wrote:
>>> 
>>> Hi,
>>> 
>>> I noticed stack overflow issues because of endless recursion on Big Endian
>> platforms (s390 and PPC64) in several tests:
>>> 
>>> E.g. Int64VectorLoadStoreTests:
>>> 
>>>       at
>> jdk.incubator.vector/jdk.incubator.vector.IntVector.maybeSwap(IntVector.j
>> ava:3330)
>>>       at
>> jdk.incubator.vector/jdk.incubator.vector.IntVector.intoByteBuffer(IntVecto
>> r.java:3151)
>>>       at
>> jdk.incubator.vector/jdk.incubator.vector.AbstractVector.defaultReinterpret
>> (AbstractVector.java:505)
>>>       at
>> java.base/jdk.internal.vm.vector.VectorSupport.convert(VectorSupport.java
>> :441)
>>>       at
>> jdk.incubator.vector/jdk.incubator.vector.AbstractVector.convert0(Abstract
>> Vector.java:686)
>>>       at
>> jdk.incubator.vector/jdk.incubator.vector.AbstractVector.asVectorRawTemp
>> late(AbstractVector.java:173)
>>>       at
>> jdk.incubator.vector/jdk.incubator.vector.AbstractVector.asByteVectorRawT
>> emplate(AbstractVector.java:179)
>>>       at
>> jdk.incubator.vector/jdk.incubator.vector.Int64Vector.asByteVectorRaw(Int
>> 64Vector.java:177)
>>>       at
>> jdk.incubator.vector/jdk.incubator.vector.Int64Vector.asByteVectorRaw(Int
>> 64Vector.java:41)
>>>       at
>> jdk.incubator.vector/jdk.incubator.vector.IntVector.reinterpretAsBytes(IntV
>> ector.java:3366)
>>>       at
>> jdk.incubator.vector/jdk.incubator.vector.IntVector.maybeSwap(IntVector.j
>> ava:3330)
>>> 
>>> Note that maybeSwap is endianness sensitive:
>>>   IntVector maybeSwap(ByteOrder bo) {
>>>       if (bo != NATIVE_ENDIAN) {
>>>           return this.reinterpretAsBytes()
>>>               .rearrange(swapBytesShuffle())
>>>               .reinterpretAsInts();
>>>       }
>>>       return this;
>>>   }
>>> 
>>> How is this supposed to work?
>>> Is anything platform specific missing?
>>> 
>>> Thanks and best regards,
>>> Martin
>>> 
> 



More information about the hotspot-compiler-dev mailing list