jdk_vector_long128_j9_0 Timeout

[KavinSatheeskumar]

Failure link

• test category: openjdk
• test target name: jdk_vector_long128_j9_0
• OS/architecture: openjdk_x86-64_linux
• public build SHAs (i.e. java -version output), in Grinder provides JDK_VERSION/JDK_IMPL info and helps identify point at which regression introduced:

Eclipse OpenJ9 VM (build 21.0.10-internal-adhoc.jenkins.BuildJDK21x86-64linuxjitPersonal-master-21618cc8d83, JRE 21 Linux amd64-64-Bit Compressed References 20251127_425 (JIT enabled, AOT enabled)
OpenJ9   - 21618cc8d83
OMR      - 1ff35339a8a
JCL      - 8bf875860ad based on jdk-21.0.10+3)

Grinder link:
https://hyc-runtimes-jenkins.swg-devops.com/job/Grinder/56589/

Optional info

This is a re-creation of #23036 with updated information

Note, this seems to be a jitserver specific issue

Failure output (captured from console output)

Include test case name, stack trace output. If test fails with a crash, please include a link to the artifacts (xxxx_test_output.tar.gz) as they include the core/dmp files. Artifacts are either stored as an attachment to the CI server job itself or as a link from the job to an Artifactory location.

test name: jdk_vector_long128_j9_0
output:

TEST RESULT: Error. Program `/home/jenkins/workspace/Grinder/jdkbinary/j2sdk-image/bin/java' timed out (timeout set to 2400000ms, elapsed time including timeout handling was 2749472ms).

[pshipton]

@gita-omr @mpirvu fyi

[mpirvu]

I reproduced this locally with JDK25 build. The test timeouts but maybe it doesn't have enough time to finish. There are very many scorching compilations and many of them fail with compilationHeapLimitExceeded after being retried 3 times. In each attempt I see 8-22 sec being wasted on failed compilations. The test uses synchronous compilations, so the app threads will be blocks until these long scorching compilations are performed:

-Xjit:{*Long128VectorTests*}(count=1,enforceVectorAPIExpansion),disableAsyncCompilation,disableSuffixLogs,verbose={vectorAPI} 

A few questions:

• Do we really need scorching compilations for vectorAPI to kick in?
• Can we avoid trying the same compilation 3 times?

[mpirvu]

If I double the timeout then the so called 'hang' disappears.
The output from the test is ambiguous though:

Test results: passed: 1
Report written to /home/mpirvu/FullJava25/Test/aqa-tests/TKG/output_17644589967122/jdk_vector_long128_j9_0/report/html/report.html
Results written to /home/mpirvu/FullJava25/Test/aqa-tests/TKG/output_17644589967122/jdk_vector_long128_j9_0/work
grep #VECTOR API /home/mpirvu/FullJava25/Test/aqa-tests/TKG/../TKG/output_17644589967122/jdk_vector_long128_j9_0/work/jdk/incubator/vector/Long128VectorTests.jtr
-----------------------------------
jdk_vector_long128_j9_0_FAILED

[gita-omr]

If I double the timeout then the so called 'hang' disappears. The output from the test is ambiguous though:

Test results: passed: 1
Report written to /home/mpirvu/FullJava25/Test/aqa-tests/TKG/output_17644589967122/jdk_vector_long128_j9_0/report/html/report.html
Results written to /home/mpirvu/FullJava25/Test/aqa-tests/TKG/output_17644589967122/jdk_vector_long128_j9_0/work
grep #VECTOR API /home/mpirvu/FullJava25/Test/aqa-tests/TKG/../TKG/output_17644589967122/jdk_vector_long128_j9_0/work/jdk/incubator/vector/Long128VectorTests.jtr
-----------------------------------
jdk_vector_long128_j9_0_FAILED

Yes, the test case is considered failed if grep #VECTOR API did not find anything, which means nothing was vectorized.

[gita-omr]

A few questions:

* Do we really need scorching compilations for vectorAPI to kick in?

* Can we avoid trying the same compilation 3 times?

1. We don't really need scorching. We could remove enforceVectorAPIExpansion
2. I am not sure why we are trying 3 times. Is it because the scorching level is enforced by that option? Generally, VectorAPIExpanstion should make the method much simpler.