RFR: 8318306: java/util/Arrays/Sorting.java fails with "Array is not sorted at 8228-th position: 8251.0 and 8153.0"

[Tobias Hartmann]

On Tue, 17 Oct 2023 22:57:34 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

> The goal of this PR is to address the failure of AVX512 sort test when the following JVM options are enabled (particularly `-XX:+DeoptimizeALot`) : 
> `-Xcomp -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:-TieredCompilation -XX:+DeoptimizeALot`
> 
> ### Description of the error: 
> The sorting test (test/jdk/java/util/Arrays/Sorting.java) usually fails as shown below (from JBS bug report):
> 
> [Arrays.parallelSort] 'Test with check sum' length = 10000, random = C0FFEE, m = 128, CHAR STAGGER
> [Arrays.parallelSort] 'Test with check sum' length = 10000, random = C0FFEE, m = 128, SHORT STAGGER
> [Arrays.parallelSort] 'Test with check sum' length = 10000, random = C0FFEE, m = 128, FLOAT STAGGER
> ----------System.err:(25/1026)----------
> 
> *** TEST FAILED ***
> 
> Array is not sorted at 8228-th position: 8251.0 and 8153.0
> 
> java.lang.RuntimeException: Test failed
> at Sorting.fail(Sorting.java:644)
> at Sorting.checkSorted(Sorting.java:892)
> at Sorting.checkSorted(Sorting.java:841)
> at Sorting.checkWithCheckSum(Sorting.java:638)
> at Sorting.testWithCheckSum(Sorting.java:438)
> at Sorting.testBasic(Sorting.java:109)
> at Sorting.testCore(Sorting.java:122)
> at Sorting.testAll(Sorting.java:140)
> at Sorting.testAll(Sorting.java:135)
> at Sorting.main(Sorting.java:85)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> at java.base/java.lang.Thread.run(Thread.java:1570)
> 
> JavaTest Message: Test threw exception: java.lang.RuntimeException: Test failed
> JavaTest Message: shutting down test
> 
> STATUS:Failed.`main' threw exception: java.lang.RuntimeException: Test failed
> 
> ---------------------------------
> ### Reproducing the error:
> #### (1) Using test/jdk/java/util/Arrays/Sorting.java:  
> `jtreg -jdk:$JDK_HOME/build/linux-x86_64-server-slowdebug/jdk/ -Xcomp -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:-TieredCompilation -XX:+DeoptimizeALot -timeoutFactor:100 -verbose:all test/jdk/java/util/Arrays/Sorting.java`
> 
> This failure was also reproduced independently by the author of this PR as follows:
> **example 1:**
> 
> 
> [Arrays.parallelSort] 'Test with check sum' length = 10000, random = C0FFEE, m = 2048, DOUBLE REPEATED
> [Arrays.parallelSort] 'Test with check sum' length = 10000, random = C0FFEE, m = 2048, INT    DUPLICATED
> STDERR:
> *** TEST FAILED ***
> Array is not...

Thanks for quickly jumping on this, Vamsi. Could you please add a description to the PR of what the problem is and what your fix does?

Are you able to reproduce the issue? A targeted regression test would be great.

> Thus the proposed fix is to add the guards for deoptimization to ensure that the correct pivotIndices is returned even when deoptimization happen

Isn't the problem that we can deopt when calling into the runtime to allocate the array and that we then need to make sure that we re-execute the bytecode? Anyway, the fix looks good to me and is in-line with other places like `LibraryCallKit::inline_multiplyToLen` where we perform array allocation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16230#issuecomment-1767914582
PR Comment: https://git.openjdk.org/jdk/pull/16230#issuecomment-1770255112