C2 compilation fails with "there should be an oop in OopMap instead of a live raw oop at safepoint"

XMLWordPrintable

    • Type: Bug
    • Resolution: Unresolved
    • Priority: P3
    • 27
    • Affects Version/s: 16
    • Component/s: hotspot

      Running the following tests with -XX:TrackedInitializationLimit=0 triggers an assert:

      compiler/membars/TestMemBarAcquire.java
      compiler/macronodes/TestEliminationOfAllocationWithoutUse.java
      compiler/uncommontrap/UncommonTrapStackBang.java

      Easily reproducible with replay compilation on Linux AArch64:

      java -XX:+ReplayCompiles -XX:+ReplayIgnoreInitErrors -XX:ReplayDataFile=replay_pid2098300.log -XX:TrackedInitializationLimit=0 -XX:RepeatCompilation=1000 -XX:+StressGCM

        64 Phi === 31 65 47 [[ 63 ]] #rawptr:BotPTR !jvms: TestMemBarAcquire::main @ bci:12 (line 53)
        64 Phi === 31 65 47 [[ 63 ]] #rawptr:BotPTR !jvms: TestMemBarAcquire::main @ bci:12 (line 53)
        24 safePoint === 27 0 52 0 0 25 0 53 0 [[ 26 88 62 ]] !jvms: TestMemBarAcquire::main @ bci:26 (line 52)

      # assert(false) failed: there should be an oop in OopMap instead of a live raw oop at safepoint

      Current CompileTask:
      C2:187 5 % b 4 compiler.membars.TestMemBarAcquire::main @ 2 (30 bytes)

      Stack: [0x0000ffff60072000,0x0000ffff60270000], sp=0x0000ffff6026b310, free space=2020k
      Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
      V [libjvm.so+0x5fc3dc] OopFlow::build_oop_map(Node*, int, PhaseRegAlloc*, int*)+0xf1c (buildOopMap.cpp:365)
      V [libjvm.so+0x5fcbc0] OopFlow::compute_reach(PhaseRegAlloc*, int, Dict*)+0x270
      V [libjvm.so+0x5fe754] PhaseOutput::BuildOopMaps()+0x1564
      V [libjvm.so+0x1322cec] PhaseOutput::Output()+0xa9c
      V [libjvm.so+0x8ce67c] Compile::Code_Gen()+0x3f8
      V [libjvm.so+0x8d0894] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1540
      V [libjvm.so+0x72cd80] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x17c
      V [libjvm.so+0x8dc554] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x834
      V [libjvm.so+0x8dd034] CompileBroker::compiler_thread_loop()+0x514
      V [libjvm.so+0xd3fd0c] JavaThread::thread_main_inner()+0xcc
      V [libjvm.so+0x15a3320] Thread::call_run()+0xac
      V [libjvm.so+0x12f9d44] thread_native_entry(Thread*)+0x130

      TestMemBarAcquire::main is really simple, so I assume it can easily be adjusted to reproduce even without -XX:TrackedInitializationLimit=0 by simply adding more fields to reach the default limit.

            Assignee:
            Unassigned
            Reporter:
            Tobias Hartmann
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: