JDK-8251994 : VM crashed running TestComplexAddrExpr.java test with -XX:UseAVX=X
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9,11.0.9,11-pool,16
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2020-08-18
  • Updated: 2021-02-02
  • Resolved: 2020-10-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 16
11.0.11-oracleFixed 16 b22Fixed
Related Reports
Duplicate :  
JDK-8259361 - Bug cause by -XX:+AllowVectorizeOnDemand in array with intersecting ranges
Relates :  
JDK-8249749 - modify a primitive array through a stream and a for cycle causes jre crash
Relates :  
JDK-8260943 - Revisit vectorization optimization added by 8076284
Description
New test compiler/vectorization/TestComplexAddrExpr.java added by JDK-8249749 fails when run with -XX:UseAVX=X

# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (src/hotspot/share/opto/superword.cpp:1723), pid=5029, tid=5043
#  assert(my_pack(s) == __null) failed: only in one pack
# Problematic frame:
# V  [libjvm.so+0x16254d6]  SuperWord::construct_my_pack_map()+0x496
#

Current CompileTask:
C2:    313   95 %     4       java.util.stream.Streams$RangeIntSpliterator::forEachRemaining @ 34 (65 bytes)

Stack: [0x00007f56518ee000,0x00007f56519ef000],  sp=0x00007f56519e9600,  free space=1005k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x16254d6]  SuperWord::construct_my_pack_map()+0x496
V  [libjvm.so+0x163086f]  SuperWord::SLP_extract()+0x22f
V  [libjvm.so+0x1630f95]  SuperWord::transform_loop(IdealLoopTree*, bool)+0x205
V  [libjvm.so+0x118cae1]  PhaseIdealLoop::build_and_optimize(LoopOptsMode)+0x1101
V  [libjvm.so+0x900c2e]  PhaseIdealLoop::optimize(PhaseIterGVN&, LoopOptsMode)+0x31e
V  [libjvm.so+0x8fe391]  Compile::Optimize()+0xd61
V  [libjvm.so+0x8ffd80]  Compile::Compile(ciEnv*, ciMethod*, int, bool, bool, bool, bool, DirectiveSet*)+0x1500
Comments
The test passed in jdk16 ATR. Also manually run the test with "-Xbatch -XX:CICompilerCount=2 -XX:UseAVX=3" and jdk16b31, no failure.
13-01-2021
Fix request (11u) I would like to downport this for parity with 11.0.11-oracle. Applies clean.
22-12-2020
Changeset: a7fa1b70 Author: Vladimir Kozlov <kvn@openjdk.org> Date: 2020-10-26 19:40:48 +0000 URL: https://git.openjdk.java.net/jdk/commit/a7fa1b70
26-10-2020
I ran next jtreg tests with -XX:+TraceNewVectors and compared number of vector nodes created before and after fix: compiler/c2/cr6340864/ compiler/codegen/ compiler/loopopts/superword/ compiler/vectorization There was no change in number of vector nodes.
26-10-2020
For record. To reproduce failrue with latest JDK 16: java -Xbatch -XX:CICompilerCount=2 -XX:UseAVX=3 TestComplexAddrExpr test6 Run test6 ... # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/superword.cpp:1726 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/workspace/open/src/hotspot/share/opto/superword.cpp:1726), pid=20595, tid=20607 # assert(my_pack(s) == __null) failed: only in one pack # # JRE version: Java(TM) SE Runtime Environment (16.0+22) (fastdebug build 16-ea+22-1264) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 16-ea+22-1264, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x17bc2e7] SuperWord::construct_my_pack_map()+0x487 #
25-10-2020
Here's the logs for my sighting in my jdk-16+12 stress testing run: $ unzip -l jdk-16+12_linux.8251994.zip Archive: jdk-16+12_linux.8251994.zip Length Date Time Name --------- ---------- ----- ---- 141090 2020-08-20 18:50 jdk-16+12_1/failures.linux-x86_64/hs_err_pid1812.log 139983 2020-08-20 22:50 jdk-16+12_1/failures.linux-x86_64/hs_err_pid26887.log 141315 2020-08-21 22:38 jdk-16+12_2/failures.linux-x86_64/hs_err_pid12909.log 140263 2020-08-22 02:30 jdk-16+12_2/failures.linux-x86_64/hs_err_pid3494.log 140919 2020-08-22 20:01 jdk-16+12_3/failures.linux-x86_64/hs_err_pid16279.log 139907 2020-08-22 23:51 jdk-16+12_3/failures.linux-x86_64/hs_err_pid7540.log 37582 2020-08-20 22:50 jdk-16+12_1/failures.linux-x86_64/TestComplexAddrExpr.jtr.fastdebug 37612 2020-08-20 18:50 jdk-16+12_1/failures.linux-x86_64/TestComplexAddrExpr.jtr.slowdebug 37600 2020-08-22 02:30 jdk-16+12_2/failures.linux-x86_64/TestComplexAddrExpr.jtr.fastdebug 37363 2020-08-21 22:40 jdk-16+12_2/failures.linux-x86_64/TestComplexAddrExpr.jtr.slowdebug 37579 2020-08-22 23:51 jdk-16+12_3/failures.linux-x86_64/TestComplexAddrExpr.jtr.fastdebug 37615 2020-08-22 20:01 jdk-16+12_3/failures.linux-x86_64/TestComplexAddrExpr.jtr.slowdebug --------- ------- 1068828 12 files
24-08-2020
I found the cause of the issue. To improve a chance to vectorize a loop, superword tries to hoist loads to the beginning of loop by replacing their memory input with corresponding (same memory slice) loop's memory Phi : http://hg.openjdk.java.net/jdk/jdk/file/8f73aeccb27c/src/hotspot/share/opto/superword.cpp#l471 Originally loads are ordered by corresponding stores on the same memory slice. But when they are hoisted they loose that ordering - nothing enforce the order. In test6 case the ordering is preserved (luckily?) after hoisting only when vector size is 32 bytes (avx2) but they become unordered with 16 (avx=0 or avx1) or 64 (avx512) bytes vectors. The mystery of why the test did not fail in our teting environment is also solved! We have old Skylake machines (even my local machine) for which AVX is switched to avx2: http://hg.openjdk.java.net/jdk/jdk/file/8f73aeccb27c/src/hotspot/cpu/x86/vm_version_x86.cpp#l679 I have simple fix (use original loads ordering indexes) but looking on the code which causing the issue I see that it is bogus/incomplete - it does not help cases listed for JDK-8076284 changes: https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-April/017645.html Using unrolling and cloning information to vectorize is interesting idea but as I see it is not complete. Even if pack_parallel() method is able created packs they are all removed by filter_packs() method. And additionally the above cases are vectorized without hoisting loads and pack_parallel - I verified it. That code is useless now and I will put it under flag to not run it. It needs more work to be useful. I reluctant to remove the code because may be in a future we will have time to invest into it.
21-08-2020
I marked 11u-oracle as affected because I backported 8249749 fix and new test there. OpenJDK 11u does not have 8249749 backport yet. But I tested it today and it fails the same way. I also found old JDK 9 binaries and tested them. Failed too. So this is long existing issue (not related to 8249749 changes) which was exposed by new test. Latest JDK 8u is not affected.
19-08-2020
The setting of UseAVX is complex and higly depends on the CPU model. And not only on the physically installed model, virtualization environments may disable instruction set extensions and hence affect UseAVX.
19-08-2020
Test also fails reproducible in our CI. It fails on Linux x86_64, Linux_aarch64, Windows x86_64 and macOS. We do not specify the UseAVX flag. Example VM arguments and CPU info from a hs_err file on Linux_x86: jvm_args: -Dtest.vm.opts=-Xmx768m -Djava.awt.headless=true -Djava.util.prefs.userRoot=/nightly/test/jtreg_hotspot_tier1_work/tmp -Djava.io.tmpdir=/nightly/test/jtreg_hotspot_tier1_work/tmp -ea -esa -Dtest.tool.vm.opts=-J-Xmx768m -J-Djava.awt.headless=true -J-Djava.util.prefs.userRoot=/nightly/test/jtreg_hotspot_tier1_work/tmp -J-Djava.io.tmpdir=/nightly/test/jtreg_hotspot_tier1_work/tmp -J-ea -J-esa -Dtest.compiler.opts= -Dtest.java.opts= -Dtest.jdk=/nightly/test/sapjvm_16 -Dcompile.jdk=/nightly/test/sapjvm_16 -Dtest.timeout.factor=6.0 -Dtest.nativepath=/nightly/test/grmpf/testdata/jtreg/jtreg_test_16/test/hotspot/jtreg/native -Dtest.root=/nightly/test/grmpf/testdata/jtreg/jtreg_test_16/test/hotspot/jtreg -Dtest.name=compiler/vectorization/TestComplexAddrExpr.java -Dtest.file=/nightly/test/grmpf/testdata/jtreg/jtreg_test_16/test/hotspot/jtreg/compiler/vectorization/TestComplexAddrExpr.java -Dtest.src=/nightly/test/grmpf/testdata/jtreg/jtreg_test_16/test/hotspot/jtreg/compiler/vectorization -Dtest.src.path=/nightly/test/grmpf/testdata/jtreg/jtreg_test_16/test/hotspot/jtreg/compiler/vectorization -Dtest.classes=/nightly/test/jtreg_hotspot_tier1_work/JTwork/classes/compiler/vectorization/TestComplexAddrExpr.d -Dtest.class.path=/nightly/test/jtreg_hotspot_tier1_work/JTwork/classes/compiler/vectorization/TestComplexAddrExpr.d -Xmx768m -Djava.awt.headless=true -Djava.util.prefs.userRoot=/nightly/test/jtreg_hotspot_tier1_work/tmp -Djava.io.tmpdir=/nightly/test/jtreg_hotspot_tier1_work/tmp -ea -esa -Djava.library.path=/nightly/test/grmpf/testdata/jtreg/jtreg_test_16/test/hotspot/jtreg/native java_command: com.sun.javatest.regtest.agent.MainWrapper /nightly/test/jtreg_hotspot_tier1_work/JTwork/compiler/vectorization/TestComplexAddrExpr.d/main.5.jta test6 CPU: total 8 (initial active 8) (1 cores per cpu, 1 threads per core) family 6 model 85 stepping 7 microcode 0x500002c, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, vzeroupper, avx, avx2, aes, clmul, erms, rtm, 3dnowpref, lzcnt, tsc, tscinvbit, bmi1, bmi2, adx, avx512f, avx512dq, avx512cd, avx512bw, avx512vl, fma, clflush, clflushopt, clwb Can I provide any other info that might help to find the reason=
19-08-2020
It fail OSR compilation for sub-test 'test6'. Test fails when some values for UseAVX flag specified. For some reasons it passes if UseAVX is not specified on command line (on my machine which supports AVX512).
18-08-2020