• Type: Bug
• Component: hotspot
• Sub-Component: compiler
• Affected Version: 9,10,11,12,16

• Priority: P4
• Status: Open
• Resolution: Unresolved

• Submitted: 2017-01-31
• Updated: 2022-12-23

Other
tbdUnresolved

dominated_by() introduces conI in split_if_with_blocks(). it's possible that ConI1 or conI0 is a new node for igvn. in my case, it's 172 ConI === 0 [[ 131 ]] #int:1 - 0 Root === 0 58 96 165 155 141 [[ 0 1 3 149 136 35 43 53 70 97 105 112 169 ]] inner + 0 Root === 0 58 96 165 155 141 [[ 0 1 3 149 136 35 43 53 70 97 105 112 169 172 ]] inner 3 Start === 3 0 [[ 3 5 6 7 8 9 10 11 ]] #{0:control, 1:abIO, 2:memory, 3:rawptr:BotPTR, 4:return_address, 5:java/lang/String:NotNull:exact *, 6:int} 5 Parm === 3 [[ 48 ]] Control !jvms: String::charAt @ bci:-1 6 Parm === 3 [[ 155 137 163 92 54 ]] I_O !jvms: String::charAt @ bci:-1 @@ -40,8 +40,8 @@ 118 IfTrue === 168 [[ 131 ]] #1 !jvms: StringLatin1::charAt @ bci:7 String::charAt @ bci:12 119 IfFalse === 168 [[ 92 ]] #0 !jvms: StringLatin1::charAt @ bci:7 String::charAt @ bci:12 129 CmpU === _ 11 114 [[ 130 ]] !orig=[161] !jvms: StringLatin1::charAt @ bci:21 String::charAt @ bci:12 - 130 Bool === _ 129 [[ 131 168 ]] [lt] !orig=[162] !jvms: StringLatin1::charAt @ bci:21 String::charAt @ bci:12 - 131 RangeCheck === 118 130 [[ 132 135 ]] P=0.999999, C=-1.000000 !jvms: StringLatin1::charAt @ bci:21 String::charAt @ bci:12 + 130 Bool === _ 129 [[ 168 ]] [lt] !orig=[162] !jvms: StringLatin1::charAt @ bci:21 String::charAt @ bci:12 + 131 RangeCheck === 118 172 [[ 132 135 ]] P=0.999999, C=-1.000000 !jvms: StringLatin1::charAt @ bci:21 String::charAt @ bci:12 132 IfTrue === 131 [[ 155 143 170 ]] #1 !jvms: StringLatin1::charAt @ bci:21 String::charAt @ bci:12 135 IfFalse === 131 [[ 137 ]] #0 !jvms: StringLatin1::charAt @ bci:21 String::charAt @ bci:12 136 ConI === 0 [[ 137 ]] #int:-28 @@ -60,3 +60,4 @@ 168 RangeCheck === 103 130 [[ 119 118 ]] P=1.000000, C=5375.000000 !orig=[117] !jvms: StringLatin1::charAt @ bci:7 String::charAt @ bci:12 169 ConI === 0 [[ 92 ]] #int:-27 170 LoadUB === 132 7 146 [[ 155 ]] @byte[int:>=0]:exact+any *, idx=7; #int:0..255 !orig=[171],[150] !jvms: StringLatin1::charAt @ bci:25 String::charAt @ bci:12 + 172 ConI === 0 [[ 131 ]] #int:1 here is a patch candidate to fix it. --- a/src/hotspot/share/opto/loopopts.cpp +++ b/src/hotspot/share/opto/loopopts.cpp @@ -244,7 +244,11 @@ void PhaseIdealLoop::dominated_by( Node *prevdom, Node *iff, bool flip, bool exc pop = Op_IfTrue; } // 'con' is set to true or false to kill the dominated test. - Node *con = _igvn.makecon(pop == Op_IfTrue ? TypeInt::ONE : TypeInt::ZERO); + Node* con = _igvn.makecon(pop == Op_IfTrue ? TypeInt::ONE : TypeInt::ZERO); + if (!has_node(con)) { + IdealLoopTree* loop = get_loop(iff); + loop->_body.push(con); + } set_ctrl(con, C->root()); // Constant gets a new use // Hack the dominated test _igvn.replace_input_of(iff, 1, con); but it's not the only problem that can't enable VerifyLoopOptimizations. eg. IdealLoopTree::verify_tree doesn't support StripedMinedLoop or RangeCheck. I suggest we file some sub-tasks to track them 19-10-2020 for -XX:+VerifyLoopOptimizations --version, I have a reduced compilation, c2 hits the assertion when it compiles java.lang.charAt(); java -XX:CompileOnly=java.lang.String::charAt -XX:CompileOnly=java.lang.String::isLatin1 -XX:CompileOnly=java.lang.StingLatin1.charAt -Xbatch -XX:+TraceLoopOpts -XX:+PrintCompilation -XX:CompileCommand=quiet -XX:+PrintInlining -XX:-TieredCompilation -XX:+VerifyLoopOptimizations --version Further, -XX:-SplitIfBlocks dodges this problem. it seems PhaseIdealLoop::split_if_with_blocks() is the culprit. perhaps, it introduces a new ConI but doesn't add it to the current ILT->_body. 19-10-2020 The flag is still broken in JDK 16. Example: java -XX:+VerifyLoopOptimizations --version Log: Verify has that we do not: 171 ConI === 0 [[ 131 ]] #int:1 # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/loopnode.cpp:3538 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/christian/jdk/open/src/hotspot/share/opto/loopnode.cpp:3538), pid=19553, tid=19565 # assert(!fail) failed: loop body mismatch # # JRE version: Java(TM) SE Runtime Environment (16.0) (slowdebug build 16-internal+0-2020-06-15-1404004.christian...) # Java VM: Java HotSpot(TM) 64-Bit Server VM (slowdebug 16-internal+0-2020-06-15-1404004.christian..., mixed mode, tiered, compressed oops, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0xcf7b22] IdealLoopTree::verify_tree(IdealLoopTree*, IdealLoopTree const*) const+0x958 22-06-2020 sure, will do that after [1], Thanks for the inputs, Nils. [1]presently i am not sure how rotten loop verification code is.. i stopped after seeing 5 issues in "java -version", will check if it is really beneficial keeping the option in this condition. 19-12-2017 I ran into this too, thanks for fixing! The misplaced rm in PhaseIdealLoop::build_and_optimize has been there since 2011. Please add some testing (in tier 1-3) that exercise this code so it doesn't bit rot again. 18-12-2017 5) next problem is due to JDK-7008866 we have modified loop ctrl info(node placement info, early here) in PhaseIdealLoop::split_thru_phi, so it is different in actual run and verification run, as verification run do late/apt placements. i may need to skip this too, may be skip loop verification for this case altogether! + // Don't move x into a loop if its uses are + // outside of loop. Otherwise x will be cloned + // for each use outside of this loop. + IdealLoopTree *use_loop = get_loop(region); + if (!new_loop->is_member(use_loop) && + (old_loop == NULL || !new_loop->is_member(old_loop))) { + // Take early control, later control will be recalculated + // during next iteration of loop optimizations. + new_ctrl = get_early_ctrl(x); + new_loop = get_loop(new_ctrl); 29-11-2017 fixed first 3 issues, next problem 4) ctrl is not same in verification phase, graph shaped changed and missed ctrl update? [related to JDK-8139771] problem is due to dominating cast is replacing current cast node, the loop ctrl(node placement) info is different from actual graph in current run, assuming this wouldn't cause any issue in this loop-opt run, or in further runs, skipping the case in verification if (n->is_ConstraintCast()) { Node* dom_cast = n->as_ConstraintCast()->dominating_cast(&_igvn, this); // ConstraintCastNode::dominating_cast() uses node control input to determine domination. // Node control inputs don't necessarily agree with loop control info (due to // transformations happened in between), thus additional dominance check is needed // to keep loop info valid. if (dom_cast != NULL && is_dominator(get_ctrl(dom_cast), get_ctrl(n))) { _igvn.replace_node(n, dom_cast); return dom_cast; } } 29-11-2017 1) PhaseIdealLoop ds are lost due to misplaced rm ? 2) major progress is not restored on all verify exit path ? 3) counted loop guard verification fails some times, need to check cases it fails and fix it. working on 3 now! 23-11-2017 multiple causes! 23-11-2017 Fastdebug build of 10 (around b30) fails with SIGSEGV on Linux for java -XX:+VerifyLoopOptimizations -version This happens on amd64 and aarch64. The logs are attached. 07-11-2017 sure, Zoltan. Thank you! 03-02-2017 Hi Jamsheed, this is a C2-specific problem. I'm not sure if we want/can spend time on this in the (near) future, but could you please track of the bug until we know what we want to do with it? Thank you! Zoltan 02-02-2017 Deferring to 10. 02-02-2017 ILW=crash, fastdebug build only (flag is not available in product), flag is disabled in product builds therefore customer/end-user is not affected = HLL = P4 02-02-2017