JDK-8328181 : C2: assert(MaxVectorSize >= 32) failed: vector length should be >= 32
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 17,21,23
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: x86_64
  • Submitted: 2024-03-14
  • Updated: 2024-08-01
  • Resolved: 2024-04-09
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 23
23 b18Fixed
Related Reports
Blocks :  
JDK-8320224 - [IR Framework] Add MaxVectorSize to JTREG_WHITELIST_FLAGS
Relates :  
JDK-8257772 - Vectorizing clear memory operation using AVX-512 masked operations
Relates :  
JDK-8332487 - Regression in Crypto-AESGCMBench.encrypt (and others) after JDK-8328181
Description
I ran this:

~/Documents/jtreg/bin/jtreg -va -s -jdk:/oracle-work/jdk-fork2/build/linux-x64-debug/jdk -javaoptions:"-XX:MaxVectorSize=8" -J-Djavatest.maxOutputSize=10000000 /oracle-work/jdk-fork2/open/test/hotspot/jtreg/compiler/c2/ClearArray.java

And got that:

# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/oracle-work/jdk-fork2/open/src/hotspot/cpu/x86/macroAssembler_x86.cpp:9473), pid=2498389, tid=2498406
#  assert(MaxVectorSize >= 32) failed: vector length should be >= 32
#
# JRE version: Java(TM) SE Runtime Environment (23.0) (fastdebug build 23-internal-2024-03-12-0734066.emanuel...)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 23-internal-2024-03-12-0734066.emanuel..., mixed mode, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x132c9e5]  MacroAssembler::fill64(Address, XMMRegister, bool)+0x1c5
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /oracle-work/jdk-fork2/build/linux-x64-slowdebug/jdk/bin/JTwork/scratch/core.2498389)
#
# An error report file with more information is saved as:
# /oracle-work/jdk-fork2/build/linux-x64-slowdebug/jdk/bin/JTwork/scratch/hs_err_pid2498389.log
#
# Compiler replay data is saved as:
# /oracle-work/jdk-fork2/build/linux-x64-slowdebug/jdk/bin/JTwork/scratch/replay_pid2498389.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp


I suspect that this is a AVX512 feature, since it only seems to reprodue on such machines. But setting -XX:UseAVX=2 does not stop the compiler from using fill64, which seems to be an AVX512 feature.
Comments
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/18464 Date: 2024-03-24 09:58:59 +0000
01-08-2024
Changeset: fbc1e666 Author: Jatin Bhateja <jbhateja@openjdk.org> Date: 2024-04-09 01:37:38 +0000 URL: https://git.openjdk.org/jdk/commit/fbc1e6661e26c30a9cf7bc57afd70fde1c642bcb
09-04-2024
[~jbhateja] I'm assigning this to you, since it is a regression of your JDK-8257772.
15-03-2024
On second thought: I think the code just does not expect MaxVectorSize to ever be less than 32, since there is an assert that has UseAVX > 2. But of course one can manually set MaxVectorSize, and trigger the assert. Just weakening the assert is not really a great solution: If I set MaxVectorSize=8, then we should probably not call fill32, which indicates that we are doing a 32byte vector store.
15-03-2024
This is a regression from JDK-8257772 in JDK 17 b03. ILW = Assert during C2 compilation, on AVX3 machines with non-default MaxVectorSize, set MaxVectorSize to default or exclude method from C2 compilation = HLM = P3
15-03-2024
BTW: on AVX3 machines, setting UseAVX=2 for this test has no effect: the test internally sets "-XX:UseAVX=3", and so overwrites the external flag, and it still crashes. To me, this confirms that this is a AVX512 issue.
14-03-2024
First analysis, running with "-XX:MaxVectorSize=8": void MacroAssembler::fill64(Address dst, XMMRegister xmm, bool use64byteVector) { assert(MaxVectorSize >= 32, "vector length should be >= 32"); if (!use64byteVector) { fill32(dst, xmm); fill32(dst.plus_disp(32), xmm); } else { evmovdquq(dst, xmm, Assembler::AVX_512bit); } } The "use64byteVector" seems to indicate that we can avoid using 64-byte, and the if sais as much. Maybe we have to limit the assert. I think the assert should also require AVX=3, and the corresponding feature. It was called from this method: // Clearing constant sized memory using YMM/ZMM registers. void MacroAssembler::clear_mem(Register base, int cnt, Register rtmp, XMMRegister xtmp, KRegister mask) { assert(UseAVX > 2 && VM_Version::supports_avx512vlbw(), ""); bool use64byteVector = (MaxVectorSize > 32) && (VM_Version::avx3_threshold() == 0); It looks like here, we actively require more than AVX2, and also some AVX512 feature.
14-03-2024