JDK-8288883 : C2: assert(allow_address || t != T_ADDRESS) failed after JDK-8283091
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 20
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2022-06-21
  • Updated: 2022-07-25
  • Resolved: 2022-07-18
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 20
20 b07Fixed
Related Reports
Relates :  
JDK-8283091 - Support type conversion between different data sizes in SLP
Description
"assert(allow_address || t != T_ADDRESS) failed" was hit after JDK-8283091. So far observed on PPC64 while testing sun/java2d/marlin/CrashNaNTest.java. Unclear if other platforms are affected.

Current CompileTask:
C2:   4946   91 %  b  4       sun.java2d.marlin.Renderer::_endRendering @ 1468 (2480 bytes)

Stack snippet:
#7  0x00003fff94565840 in type2aelembytes (t=T_ADDRESS, allow_address=false)
    at src/hotspot/share/utilities/globalDefinitions.cpp:326
#8  0x00003fff94ed754c in SuperWord::data_size (this=0x3fff2bff9818, s=0x3fff24636220)
    at src/hotspot/share/opto/superword.cpp:1417
#9  0x00003fff94ed78b0 in SuperWord::adjust_alignment_for_type_conversion (this=0x3fff2bff9818, s=0x3fff246366d8, 
    t=0x3fff24636220, align=0) at src/hotspot/share/opto/superword.cpp:1454
#10 0x00003fff94ed82a0 in SuperWord::follow_def_uses (this=0x3fff2bff9818, p=0x3fff244a3c58)
    at src/hotspot/share/opto/superword.cpp:1525
#11 0x00003fff94ed76c8 in SuperWord::extend_packlist (this=0x3fff2bff9818)
    at src/hotspot/share/opto/superword.cpp:1432
#12 0x00003fff94ed2758 in SuperWord::SLP_extract (this=0x3fff2bff9818)
    at src/hotspot/share/opto/superword.cpp:519
#13 0x00003fff94ed11cc in SuperWord::transform_loop (this=0x3fff2bff9818, lpt=0x3fff244c8ba0, do_optimization=true)
    at src/hotspot/share/opto/superword.cpp:178

s in adjust_alignment_for_type_conversion is a ConvI2LNode.

New function SuperWord::adjust_alignment_for_type_conversion calls data_size which doesn't allow T_ADDRESS when calling type2aelembytes. This seems to be needed, now.
Comments
Changeset: 87340fd5 Author: Fei Gao <fgao@openjdk.org> Committer: Ningsheng Jian <njian@openjdk.org> Date: 2022-07-18 05:54:51 +0000 URL: https://git.openjdk.org/jdk/commit/87340fd5408d89d9343541ff4fcabde83548a598
18-07-2022
Thanks for your effort, [~mdoerr]!
14-07-2022
The new test has passed on PPC64 with and without the fix. But I have verified your fix by the original replay file.
14-07-2022
Hi [~mdoerr], sorry to bother you again. I added a testcase in the PR linked above. Could you please help verify if the testcase can help reproduce the failure on PPC64 and if the patch can fix it? I did the verification on AArch64 and X86 and it works on both. But I don't have any PPC64 environment. So, can you do me a favor? Thanks!
11-07-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/9391 Date: 2022-07-06 07:51:01 +0000
06-07-2022
Hi [~mdoerr], I reproduced the assertion successfully. ``` s: 6610 ConvI2L === _ 6611 [[ 6601 6605 6607 6609 ]] #long:minint..maxint:www !orig=6323,3617,1362 !jvms: Renderer::_endRendering @ bci:559 (line 905) type: 11 t: 6601 AddP === _ 1 5830 6610 [[ 6600 ]] !orig=6314,5831,[3604],2274 !jvms: Renderer::_endRendering @ bci:559 (line 905) type: 15 (T_LONG = 11 T_ADDRESS = 15) ``` Also, I used to misunderstand the backtrace above. It actually asserted in t node, rather than s node, based on the node address you provided. No confusion here. Thanks!
28-06-2022
Hi and sorry for my late response. I'm glad you were able to reproduce it. I had reproduced it by replay file, but I only have one for linuxppc64le. Seems like you already found the desired information. Thanks for investigating!
28-06-2022
Hi [~mdoerr], thanks for your update! The backtrace looks a bit weird here. It would be easy to understand if the assertion happens in t node. But it actually asserts in s node here, which has been already put in the candidate packset. Generally, superword won't put any nodes with non-primitive type to the packset, https://github.com/openjdk/jdk/blob/9dc9a64fa453d8afc90871e9663a0ccc46212f64/src/hotspot/share/opto/superword.cpp#L1202. I can't reproduce it in my aarch64/x86 environment. So, could you please help provide more log info by enabling the option -XX:+TraceSuperWord -XX:+Verbose, or dumping s and t here while assertion happens like: ``` int SuperWord::adjust_alignment_for_type_conversion(Node* s, Node* t, int align) { if (longer_type_for_conversion(s) != T_ILLEGAL || longer_type_for_conversion(t) != T_ILLEGAL) { + if (velt_basic_type(s) == T_ADDRESS) { + s->dump(); + t->dump(); + assert(false, "s can't be of T_ADDRESS type"); + } + if (velt_basic_type(t) == T_ADDRESS) { + s->dump(); + t->dump(); + assert(false, "t can't be of T_ADDRESS type"); + } align = align / data_size(s) * data_size(t); } return align; ``` Thanks!
24-06-2022
Thanks! I've seen the assertion only once so far.
22-06-2022
I'll try to fix it soon. Thanks.
22-06-2022
ILW = assert in debug build, possibly harmless in product build; unknown likelihood; no workaround = MMH = P3
22-06-2022
[~fgao], please take a look.
22-06-2022