Skip to content

8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently #28960

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
XiaohongGong wants to merge 1 commit into
base: master
Choose a base branch
from
+3 −5
Open

8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently #28960

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 3 additions & 5 deletions test/hotspot/jtreg/compiler/vectorapi/TestVectorOperationsWithPartialSize.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -76,8 +76,8 @@ public class TestVectorOperationsWithPartialSize {

random.fill(random.ints(), ia);
random.fill(random.longs(), la);
random.fill(random.floats(), fa);
random.fill(random.doubles(), da);
random.fill(random.uniformFloats(1.0f, 5.0f), fa);
random.fill(random.uniformDoubles(1.0, 5.0), da);
Comment on lines +79 to +80
Copy link
Member

@jatin-bhateja jatin-bhateja Dec 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally our tolerance window should be narrow, and increasing the tolerance range to accomodate outliers as you mentioned in your issue description may defeat the purpose.

Unlike auto-vectorization which adhears strict ordering JLS semantics, vectorAPI relaxes the reduction order to give backends leeway to use parallel reduction not strictly following the sequential order.

There are multiple considerations involed, fallback implimentation performs reduction sequentially, inline expander always relaxes the strict ordering, intrinsification of Add/Mul reductions are only supported by Aarch64, X86 and riscv.

Computing expected value using parallel reduction can be other alternative but then we may face similar problems on targets which does not intrinsify unordered reductions.

Tolerance modeling is a complex topic and involves relative and absolute error, current 10ULP absolute limit is not generic enough to handle entier spectrum of values, what you have enforced now is a range based tolerance did you try widening the input value range and confirm if 10ULP tolerance limit is sufficient ?

Copy link
Author

@XiaohongGong XiaohongGong Dec 24, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I'm trying to extend the value range to 1~3000. The tests are still running... Since the result largely depends on the random values, I run this test 500 times on SVE/NEON/X86 machines respectively (1500 times totally), and have not observed failure now. Is that fine to you? I will update the test once all tests pass. Thanks for looking at this change!

random.fill(random.uniformInts(0, ISPEC_128.length()), indices);
for (int i = 0; i < SIZE; i++) {
m[i] = i % 2 == 0;
Expand Down Expand Up @@ -160,7 +160,7 @@ private static int reduceLanes(int init, int[] arr, int vlen, binOpInt f) {
return result;
}

private static long reduceLanes(long init, long[] arr, int vlen,binOpLong f) {
private static long reduceLanes(long init, long[] arr, int vlen, binOpLong f) {
long result = init;
for (int i = 0; i < vlen; i++) {
result = f.apply(arr[i], result);
Expand Down Expand Up @@ -226,7 +226,6 @@ private static void verifyAddReductionFloat(float actual, float[] arr, int vlen)
float tolerance = Math.ulp(expected) * ROUNDING_ERROR_FACTOR_ADD;
if (Math.abs(expected - actual) > tolerance) {
throw new RuntimeException(
"assertEqualsWithTolerance" +
": expected " + expected + " but was " + actual +
" (tolerance: " + tolerance + ", diff: " + Math.abs(expected - actual) + ")"
);
Expand All @@ -243,7 +242,6 @@ private static void verifyAddReductionDouble(double actual, double[] arr, int vl
double tolerance = Math.ulp(expected) * ROUNDING_ERROR_FACTOR_ADD;
if (Math.abs(expected - actual) > tolerance) {
throw new RuntimeException(
"assertEqualsWithTolerance" +
": expected " + expected + " but was " + actual +
" (tolerance: " + tolerance + ", diff: " + Math.abs(expected - actual) + ")"
);
Expand Down