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