12 Testcases under jdk/incubator/vector/* get `java.lang.NullPointerException: Cannot load from short array because "vec2" is null` with jdk25 on AIX

[sophia-guo]

    TEST: jdk/incubator/vector/Byte64VectorLoadStoreTests.java
    TEST: jdk/incubator/vector/Byte64VectorTests.java
    TEST: jdk/incubator/vector/ByteMaxVectorLoadStoreTests.java
    TEST: jdk/incubator/vector/ByteMaxVectorTests.java
    TEST: jdk/incubator/vector/Float64VectorTests.java
    TEST: jdk/incubator/vector/FloatMaxVectorTests.java
    TEST: jdk/incubator/vector/Int64VectorLoadStoreTests.java
    TEST: jdk/incubator/vector/Int64VectorTests.java
    TEST: jdk/incubator/vector/IntMaxVectorTests.java
    TEST: jdk/incubator/vector/Short64VectorTests.java
    TEST: jdk/incubator/vector/ShortMaxVectorTests.java

error message

23:49:29  test ShortMaxVectorTests.unsliceShortMaxVectorTestsMasked(short[-i * 5], short[i * 5], mask[i % 2]): failure [10ms]
23:49:29  java.lang.NullPointerException: Cannot load from short array because "vec2" is null
23:49:29  	at jdk.incubator.vector/jdk.incubator.vector.ShortVector.bTest(ShortVector.java:476)
23:49:29  	at jdk.incubator.vector/jdk.incubator.vector.ShortVector.lambda$compareTemplate$0(ShortVector.java:2078)
23:49:29  	at java.base/jdk.internal.vm.vector.VectorSupport.compare(VectorSupport.java:602)
23:49:29  	at jdk.incubator.vector/jdk.incubator.vector.ShortVector.compareTemplate(ShortVector.java:2073)
23:49:29  	at jdk.incubator.vector/jdk.incubator.vector.ShortMaxVector.compare(ShortMaxVector.java:384)
23:49:29  	at jdk.incubator.vector/jdk.incubator.vector.ShortMaxVector.compare(ShortMaxVector.java:43)
23:49:29  	at jdk.incubator.vector/jdk.incubator.vector.ShortVector.unsliceTemplate(ShortVector.java:2370)
23:49:29  	at jdk.incubator.vector/jdk.incubator.vector.ShortVector.unsliceTemplate(ShortVector.java:2385)
23:49:29  	at jdk.incubator.vector/jdk.incubator.vector.ShortMaxVector.unslice(ShortMaxVector.java:437)
23:49:29  	at jdk.incubator.vector/jdk.incubator.vector.ShortMaxVector.unslice(ShortMaxVector.java:43)
23:49:29  	at ShortMaxVectorTests.unsliceShortMaxVectorTestsMasked(ShortMaxVectorTests.java:5548)
23:49:29  	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
23:49:29  	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
23:49:29  	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
23:49:29  	at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
23:49:29  	at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
23:49:29  	at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
23:49:29  	at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
23:49:29  	at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
23:49:29  	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
23:49:29  	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
23:49:29  	at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)

Might be related with https://bugs.openjdk.org/browse/JDK-8354383 - help needed to confirm.

[smlambert]

yes, seems likely related to https://bugs.openjdk.org/browse/JDK-8354383, also noted to cause vector test failures on riscv64 (https://bugs.openjdk.org/browse/JDK-8361532)

run against SAP machine JDK25 AIX build to see if also failing there, Grinder/14508 - appears to fail in same way as Temurin build

15:31:12  test Byte64VectorLoadStoreTests.loadShuffleArrayIOOBE(int[i * 5], l): failure [1ms]
15:31:12  java.lang.NullPointerException: Cannot load from byte/boolean array because "vec2" is null

Rerun in Grinder

[andrew-m-leonard]

Grinder using latest jdk25u "dev" HEAD, which contains jdk-25.0.1 fix for RISC-V: Several vector tests fail after JDK-8354383 : https://ci.adoptium.net/job/Grinder/15115/ - FAILS still

Was a RISCV only change. Will probably need another bug for AIX.

[andrew-m-leonard]

Raised upstream bug: https://bugs.openjdk.org/browse/JDK-8370244

[sxa]

To be clear, by excluding these have we determined that these should not be considered stop-ship issues for AIX? The riscv fix looks like it's in the hotspot code, not the test, so we presumably do have a legitimate issue here at the moment (Please correct me if I'm misinterpreting)

[andrew-m-leonard]

To be clear, by excluding these have we determined that these should not be considered stop-ship issues for AIX? The riscv fix looks like it's in the hotspot code, not the test, so we presumably do have a legitimate issue here at the moment (Please correct me if I'm misinterpreting)

My assumption is we shipped jdk-25+36 AIX with these, so will do the same

[TheRealMDoerr]

Was the test run on Power8? If so, it is probably https://bugs.openjdk.org/browse/JDK-8370803. (We use MaxVectorSize=8 on Power8 because the performance was bad with 16.)

[andrew-m-leonard]

Was the test run on Power8? If so, it is probably https://bugs.openjdk.org/browse/JDK-8370803. (We use MaxVectorSize=8 on Power8 because the performance was bad with 16.)

thanks @TheRealMDoerr yes they are Power8:

AIX 7.2 7200-05-03 | 6 x POWER8 SMT4 | 32 GB RAM | 80 GB SSD | adopt09

I will try MaxVectorSize=8

[TheRealMDoerr]

Was the test run on Power8? If so, it is probably https://bugs.openjdk.org/browse/JDK-8370803. (We use MaxVectorSize=8 on Power8 because the performance was bad with 16.)

thanks @TheRealMDoerr yes they are Power8:

AIX 7.2 7200-05-03 | 6 x POWER8 SMT4 | 32 GB RAM | 80 GB SSD | adopt09

I will try MaxVectorSize=8

That's not going to work. You will need -XX:+SuperwordUseVSX to enable the 16 Byte VectorScalarRegisters. I believe a better fix is to use -XX:-EnableVectorSupport.

[andrew-m-leonard]

Was the test run on Power8? If so, it is probably https://bugs.openjdk.org/browse/JDK-8370803. (We use MaxVectorSize=8 on Power8 because the performance was bad with 16.)

@TheRealMDoerr So I couldn't get it to pass on a Power8 node by adding just -XX:MaxVectorSize=8 however we have a new Power10 node, and it does pass on that node, so thank you for highlighting, I suspect we will need to exclude it from our testing until we have the new infra setup @sxa

[andrew-m-leonard]

Was the test run on Power8? If so, it is probably https://bugs.openjdk.org/browse/JDK-8370803. (We use MaxVectorSize=8 on Power8 because the performance was bad with 16.)

thanks @TheRealMDoerr yes they are Power8:

AIX 7.2 7200-05-03 | 6 x POWER8 SMT4 | 32 GB RAM | 80 GB SSD | adopt09

I will try MaxVectorSize=8

That's not going to work. You will need -XX:+SuperwordUseVSX to enable the 16 Byte VectorScalarRegisters. I believe a better fix is to use -XX:-EnableVectorSupport.

Ah! i'll try that thanks

[andrew-m-leonard]

Thanks @TheRealMDoerr yes using adding "-XX:+UnlockExperimentalVMOptions -XX:-EnableVectorSupport" to the testcase makes it pass on our Power8 nodes.

@smlambert Is there a way via a Grinder of setting extra jtreg options for a run testng/othervm test?

- * @run testng/othervm -XX:-TieredCompilation Byte64VectorLoadStoreTests
+ * @run testng/othervm -XX:-TieredCompilation -XX:+UnlockExperimentalVMOptions -XX:-EnableVectorSupport Byte64VectorLoadStoreTests

[smlambert]

@smlambert Is there a way via a Grinder of setting extra jtreg options for a run testng/othervm test?

yes, I believe we now can use APPLICATION_OPTIONS for that, as in the case of openjdk test group, the application is jtreg. For different test groups, the application changes jck -> jtrunner/javatest, openjdk -> jtreg, system -> STF..., APPLICATION_OPTIONS is meant as a generic way to pass options to the underlying test application/framework.

Related: https://github.com/adoptium/aqa-tests/pull/6703