JDK-8269775 : compiler/codegen/ClearArrayTest.java failed with "assert(false) failed: bad AD file"
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 17,18
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • CPU: x86_64
  • Submitted: 2021-07-01
  • Updated: 2021-07-15
  • Resolved: 2021-07-02
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 17 JDK 18
17 b30Fixed 18Fixed
Related Reports
Relates :  
JDK-8269825 - [TESTBUG] Missing testing for x86 KNL platforms
Relates :  
JDK-8269580 - assert(is_valid()) failed: invalid register (-1)
Relates :  
JDK-8269789 - Add clearArrayTests to match all the cases in the x86 ad files
Description
The following test failed in the JDK17 CI:

compiler/codegen/ClearArrayTest.java

Here's a snippet from the log file:

# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=\\matcher.cpp:1681
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (t:\\workspace\\open\\src\\hotspot\\share\\opto\\matcher.cpp:1681), pid=25284, tid=13832
#  assert(false) failed: bad AD file
#
# JRE version: Java(TM) SE Runtime Environment (17.0+30) (fastdebug build 17-ea+30-LTS-2596)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 17-ea+30-LTS-2596, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
# Core dump will be written. Default location: T:\\testoutput\\test-support\\jtreg_open_test_hotspot_jtreg_hotspot_vector_1\\scratch\\0\\hs_err_pid25284.mdmp
#
# An error report file with more information is saved as:
# T:\\testoutput\\test-support\\jtreg_open_test_hotspot_jtreg_hotspot_vector_1\\scratch\\0\\hs_err_pid25284.log
#
# Compiler replay data is saved as:
# T:\\testoutput\\test-support\\jtreg_open_test_hotspot_jtreg_hotspot_vector_1\\scratch\\0\\replay_pid25284.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#
----------System.err:(0/0)----------
----------rerun:(42/5036)*----------
Comments
The fix for this bug is in jdk-17+30-2601.
02-07-2021
Changeset: 6f0e8e79 Author: Sandhya Viswanathan <sviswanathan@openjdk.org> Date: 2021-07-02 15:33:07 +0000 URL: https://git.openjdk.java.net/jdk17/commit/6f0e8e79aaebd54a587f206a2eb920fdfd4b891d
02-07-2021
[~kvn] and [~dlong] Verified that Dean's suggestion did indeed fix the issue. Tested the compiler/codegen/ClearArrayTest.java with AVX=0,1,2,3 and also on no avx512vlbw platform. Submitting a PR: https://github.com/openjdk/jdk17/pull/199
02-07-2021
Thank you, Sandhya. Yes, it looks as correct solution.
02-07-2021
[~kvn] and [~dlong] Adding ins_cost and removing is_con() check would be the right solution. I will test this and get back to you.
01-07-2021
[~jbhateja] and [~sviswanathan] I am open for suggestion. currently as workaround fix I can only think of disabling rep_stos_im() instruction.
01-07-2021
Isn't the problem rep_stos_evex, which uses !n->in(2)->bottom_type()->is_long()->is_con(). This prevents the rule from matching with a constant --> register conversion. I suggest removing !is_con() from rep_stos_evex and adding appropriate "ins_cost" to all ClearArray rules, so that in the case of multiple matches, we break the tie based on ins_cost.
01-07-2021
It would be useful to have a command-line flag for turning off CPU features like CPU_AVX512BW.
01-07-2021
This is mess. Removing `supports_avx512vlbw` check from rep_stos_im() and MacroAssembler::clear_mem() does not help. I hit another assert: # Internal Error (/scratch/jdk17/open/src/hotspot/cpu/x86/assembler_x86.cpp:8889), pid=159934, tid=159950 # assert(((!attributes->uses_vl()) || (attributes->get_vector_len() == AVX_512bit) || (!_legacy_mode_vl) || (attributes->is_legacy_mode()))) failed: XMM register should be 0-15
01-07-2021
ILW = HMM = P2
01-07-2021
I agree the use of is_con() in the predicate can be a problem.
01-07-2021
I reproduced failure on local avx512 linux box with next hack: src/hotspot/cpu/x86/vm_version_x86.cpp @@ -770,6 +770,10 @@ void VM_Version::get_processor_features() { _features &= ~CPU_AVX512BW; _features &= ~CPU_AVX512VL; } + if (UseNewCode) { + _features &= ~CPU_AVX512BW; + _features &= ~CPU_AVX512VL; + } }
01-07-2021
Test ran on Windows with 8167M CPU and -XX:UseAVX=3 flag. It is weird VM which does not enable avx512bw and avx512vl: CPU: total 8 (initial active 8) (4 cores per cpu, 2 threads per core) family 6 model 85 stepping 4 microcode 0x1, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, avx, avx2, aes, erms, clmul, bmi1, bmi2, rtm, adx, avx512f, avx512cd, fma, vzeroupper, clflush, hv
01-07-2021
I think the issue is additional condition in predicate in rep_stos_evex() instruction which prevents it from matching any AD instruction to ClearArray: !n->in(2)->bottom_type()->is_long()->is_con()); There is instruction for constant small count but it requires `supports_avx512vlbw` support: // Small ClearArray AVX512 constant length. instruct rep_stos_im(immL cnt, rRegP base, regD tmp, rRegI zero, kReg ktmp, Universe dummy, rFlagsReg cr) %{ predicate(!((ClearArrayNode*)n)->is_large() && (UseAVX > 2 && VM_Version::supports_avx512vlbw() && n->in(2)->bottom_type()->is_long()->is_con())); Looks like JDK-8269580 missed it.
01-07-2021
Full output from Matcher: CompileCommand: compileonly *ClearArrayTest.test bool compileonly = true o273 ClearArray === o285 o266 o291 o272 [[o229 71 ]] Memory: @rawptr:BotPTR, idx=Raw; --N: o273 ClearArray === o285 o266 o291 o272 [[o229 71 ]] Memory: @rawptr:BotPTR, idx=Raw; --N: o291 ConL === o0 [[o273 ]] #long:4 IMML 20 IMML IMML8 5 IMML8 IMMUL32 10 IMMUL32 IMML32 15 IMML32 IMML_POW2 15 IMML_POW2 IMML_127 10 IMML_127 RREGL 70 loadConUL32 NO_RAX_RDX_REGL 70 loadConUL32 NO_RAX_REGL 70 loadConUL32 RAX_REGL 70 loadConUL32 RCX_REGL 70 loadConUL32 RDX_REGL 70 loadConUL32 STACKSLOTL 170 storeSSL --N: o272 AddP === _ o238 o238 o267 [[o273 ]] ANY_REGP 115 addP_rReg_imm RREGP 115 addP_rReg_imm NO_RAX_REGP 115 addP_rReg_imm NO_RBP_REGP 115 addP_rReg_imm NO_RAX_RBX_REGP 115 addP_rReg_imm RAX_REGP 115 addP_rReg_imm RBX_REGP 115 addP_rReg_imm RSI_REGP 115 addP_rReg_imm RBP_REGP 115 addP_rReg_imm RDI_REGP 115 addP_rReg_imm R15_REGP 115 addP_rReg_imm INDIRECT 115 addP_rReg_imm INDOFFSET8 5 INDOFFSET8 INDOFFSET32 15 INDOFFSET32 INDINDEX 80 INDINDEX STACKSLOTP 215 storeSSP MEMORY 5 INDOFFSET8 _AddP_any_RegP_rRegL 70 _AddP_any_RegP_rRegL --N: o238 LoadP === o5 o7 o234 [[o239 o246 o249 o252 o255 o259 o261 o261 o265 o265 o272 o272 o231 ]] @rawptr:BotPTR, idx=Raw; #rawptr:BotPTR (does not depend only on test) ANY_REGP 0 ANY_REGP RREGP 0 RREGP NO_RAX_REGP 0 NO_RAX_REGP NO_RBP_REGP 0 NO_RBP_REGP NO_RAX_RBX_REGP 0 NO_RAX_RBX_REGP RAX_REGP 0 RAX_REGP RBX_REGP 0 RBX_REGP RSI_REGP 0 RSI_REGP RBP_REGP 0 RBP_REGP RDI_REGP 0 RDI_REGP R15_REGP 0 R15_REGP INDIRECT 0 INDIRECT STACKSLOTP 100 storeSSP MEMORY 0 INDIRECT --N: o267 ConL === o0 [[o272 ]] #long:16 IMML 20 IMML IMML8 5 IMML8 IMMUL32 10 IMMUL32 IMML32 15 IMML32 IMML_POW2 15 IMML_POW2 IMML_127 10 IMML_127 RREGL 70 loadConUL32 NO_RAX_RDX_REGL 70 loadConUL32 NO_RAX_REGL 70 loadConUL32 RAX_REGL 70 loadConUL32 RCX_REGL 70 loadConUL32 RDX_REGL 70 loadConUL32 STACKSLOTL 170 storeSSL
01-07-2021
No, it can't be cause. The issue with code for ClearArray which may be caused by JDK-8269580 which was pushed today: --N: o273 ClearArray === o285 o266 o291 o272 [[o229 71 ]] Memory: @rawptr:BotPTR, idx=Raw; --N: o291 ConL === o0 [[o273 ]] #long:4 --N: o272 AddP === _ o238 o238 o267 [[o273 ]] --N: o238 LoadP === o5 o7 o234 [[o239 o246 o249 o252 o255 o259 o261 o261 o265 o265 o272 o272 o231 ]] @rawptr:BotPTR, idx=Raw; #rawptr:BotPTR (does not depend only on test) --N: o267 ConL === o0 [[o272 ]] #long:16
01-07-2021
[~jbhateja] Please, look. It is urgent.
01-07-2021