[jdk17] RFR: 8269179: Crash in TestMacroLogicVector::testSubWordBoolean: assert(_base >= VectorMask && _base <= VectorZ) failed: Not a Vector
Jie Fu
jiefu at openjdk.java.net
Thu Jun 24 01:20:30 UTC 2021
On Wed, 23 Jun 2021 04:52:09 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:
>> Hi all,
>>
>> compiler/vectorization/TestMacroLogicVector.java crashed on AVX512 machines.
>>
>> Here is the symptom and stack trace:
>>
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> # Internal Error (/jdk17/src/hotspot/share/opto/type.hpp:1717), pid=19546, tid=19562
>> # assert(_base >= VectorMask && _base <= VectorZ) failed: Not a Vector
>> #
>> # JRE version: OpenJDK Runtime Environment (17.0) (slowdebug build 17-internal+0-adhoc.jvm.jdk17)
>> # Java VM: OpenJDK 64-Bit Server VM (slowdebug 17-internal+0-adhoc.jvm.jdk17, mixed mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
>> # Problematic frame:
>> # V [libjvm.so+0x3b8483] Type::is_vect() const+0x6b
>> #
>>
>>
>> Current CompileTask:
>> C2: 2275 22 % b compiler.vectorization.TestMacroLogicVector::testSubWordBoolean @ 2 (27 bytes)
>>
>> Stack: [0x00007f0c021fa000,0x00007f0c022fb000], sp=0x00007f0c022f5e20, free space=1007k
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V [libjvm.so+0x3b8483] Type::is_vect() const+0x6b
>> V [libjvm.so+0x3da830] vector_length_in_bytes(Node const*)+0x2b
>> V [libjvm.so+0x8b1e97] State::_sub_Op_MacroLogicV(Node const*)+0x81
>> V [libjvm.so+0x8d8014] State::DFA(int, Node const*)+0x17f6
>> V [libjvm.so+0xeceb84] Matcher::Label_Root(Node const*, State*, Node*, Node*&)+0x4c0
>> V [libjvm.so+0xece218] Matcher::match_tree(Node const*)+0x206
>> V [libjvm.so+0xecc40b] Matcher::xform(Node*, int)+0x1f3
>> V [libjvm.so+0xec75f9] Matcher::match()+0xdc7
>> V [libjvm.so+0x7d9e01] Compile::Code_Gen()+0x95
>> V [libjvm.so+0x7d10f5] Compile::Compile(ciEnv*, ciMethod*, int, bool, bool, bool, bool, bool, DirectiveSet*)+0x160f
>> V [libjvm.so+0x6c17c8] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x144
>> V [libjvm.so+0x7ee2ed] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x97d
>> V [libjvm.so+0x7ece21] CompileBroker::compiler_thread_loop()+0x3dd
>> V [libjvm.so+0x80d1ab] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69
>> V [libjvm.so+0x12857f1] JavaThread::thread_main_inner()+0x17b
>> V [libjvm.so+0x1285669] JavaThread::run()+0x1d7
>> V [libjvm.so+0x1282e40] Thread::call_run()+0x180
>> V [libjvm.so+0xfc255b] thread_native_entry(Thread*)+0x18f
>>
>>
>> The reason is that for vpternlog_mem, `n->in(1)` points to BinaryNode.
>> This is incorrect since `BinaryNode->bottom_type()` returns `Type::BOTTOM`.
>> So it should be something like `n->in(1)->in(1)`.
>>
>> Thanks.
>> Best regards,
>> Jie
>
> Check introduced by 8267652, fix looks good to me.
Thanks @jatin-bhateja , @vnkozlov and @neliasso .
-------------
PR: https://git.openjdk.java.net/jdk17/pull/123
More information about the hotspot-compiler-dev
mailing list