Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8285820

C2: LCM prioritizes locally dependent CreateEx nodes over projections after 8270090

    XMLWordPrintable

Details

    • b23

    Backports

      Description

        Before JDK-8270090, CreateEx nodes *initially ready* were given priority over Proj nodes [1], but CreateEx nodes with input dependencies within the block ("locally-dependent") were given the same priority as Proj nodes [2]. That is, the ranking between CreateEx and Proj nodes was:

        1. Initially ready CreateEx nodes
        2. Proj nodes and other CreateEx nodes (tie)

        JDK-8270090 altered this ranking, giving *all* CreateEx nodes priority over Proj nodes, regardless of whether they are ready initially or not [3]. This was done based on the wrong assumption that all CreateEx nodes would be initially ready. The new ranking has triggered the following test failure, specific to x86_32 using -XX:+UseShenandoahGC, but might affect other platforms and configurations:

        $ CONF=linux-x86-server-fastdebug make run-test TEST=java/util/concurrent/tck/JSR166TestCase.java TEST_VM_OPTS="-XX:+UseShenandoahGC"

        # Internal Error (/home/shade/trunks/jdk/src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp:817), pid=3039050, tid=3039063
        # assert(res != __null) failed: need result register

        Current CompileTask:
        C2: 2791 1631 4 java.util.concurrent.LinkedTransferQueue::xfer (236 bytes)

        Stack: [0xb183f000,0xb1900000], sp=0xb18fcd00, free space=759k
        Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
        V [libjvm.so+0x14d12a0] ShenandoahBarrierSetAssembler::cmpxchg_oop(MacroAssembler*, RegisterImpl*, Address, RegisterImpl*, RegisterImpl*, bool, RegisterImpl*, RegisterImpl*)+0x710
        V [libjvm.so+0x391091] compareAndSwapP_shenandoahNode::emit(CodeBuffer&, PhaseRegAlloc*) const+0x281
        V [libjvm.so+0x1346f81] PhaseOutput::scratch_emit_size(Node const*)+0x491
        V [libjvm.so+0x1113969] MachNode::size(PhaseRegAlloc*) const+0x69
        V [libjvm.so+0x133d1db] PhaseOutput::shorten_branches(unsigned int*)+0x34b
        V [libjvm.so+0x134fde5] PhaseOutput::Output()+0xad5
        V [libjvm.so+0x96d98d] Compile::Code_Gen()+0x4dd
        V [libjvm.so+0x972a6a] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x141a
        V [libjvm.so+0x796d6f] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x89f
        V [libjvm.so+0x9844cd] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x15bd
        V [libjvm.so+0x985311] CompileBroker::compiler_thread_loop()+0x7b1
        V [libjvm.so+0x9af41b] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x2b
        V [libjvm.so+0x16ee8f8] JavaThread::thread_main_inner()+0x5b8
        V [libjvm.so+0x16f10a2] JavaThread::run()+0x402
        V [libjvm.so+0x16fa55e] Thread::call_run()+0xfe
        V [libjvm.so+0x1324ff3] thread_native_entry(Thread*)+0x123
        C [libpthread.so.0+0x7635] start_thread+0xf5

        [1] https://github.com/openjdk/jdk/blob/beedae1141b6b650dc4cedf1f038afc1c8b460dd/src/hotspot/share/opto/lcm.cpp#L1057-L1070
        [2] https://github.com/openjdk/jdk/blob/beedae1141b6b650dc4cedf1f038afc1c8b460dd/src/hotspot/share/opto/lcm.cpp#L531-L538
        [3] https://github.com/openjdk/jdk/blob/8ebea443f333ecf79d6b0fc725ededb231e83ed5/src/hotspot/share/opto/lcm.cpp#L532-L537

        Attachments

          Issue Links

            Activity

              People

                rcastanedalo Roberto Castaneda Lozano
                shade Aleksey Shipilev
                Votes:
                0 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved: