JDK-6663854 : assert(n != __null,"Bad immediate dominator info.") in C2 with -Xcomp
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 6u6,6u10,6u17
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux,linux_suse_sles_10,solaris_10
  • CPU: x86
  • Submitted: 2008-02-15
  • Updated: 2022-12-15
  • Resolved: 2010-03-10
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.
Other JDK 6 Other
1.4.2_27,hs17Fixed 6u21Fixed hs17Fixed
Related Reports
Duplicate :  
JDK-6922056 - C2Compiler crash 6.0 u17
Relates :  
JDK-6659207 - access violation in CompilerThread0
Relates :  
JDK-6944092 - JVM crashes in webserver on windows 2008
Relates :  
JDK-6675699 - need comprehensive fix for unconstrained ConvI2L with narrowed type
Relates :  
JDK-8298851 - C2: ConvL2I nodes should not be split through phis
Description
The following assertion is observed at least on linux-amd64 with both JDK 6u10 (1.6.0_10-ea-b11) and JDK 7 (1.7.0-ea-b24):
    #  src/share/vm/opto/loopnode.hpp:635
    #  assert(n != __null,"Bad immediate dominator info.")

It occurs only in -Xcomp mode. 

Product build crashes during execution.

Testcase and hs_err file are attached.
Comments
EVALUATION 6663854: assert(n != __null,"Bad immediate dominator info.") in C2 with -Xcomp Reviewed-by: kvn This is another instance of the ConvI2L problem with type information being raised to a point that it's no longer true, like the bug 6659207, resulting in top being returned and some code path being mistakenly killed. The same style of fix for 6659207 won't work in this case because there's no option to bailout if the types won't work. Instead we strip the constrained type off the ConvI2L as it is pushed up. The test case was automatically generated and I couldn't simplify it any further so it's pretty horrific looking. Tested with test case and confirmed that stripping the type doesn't effect the code quality for scimark which is very sensitive to the loss of the type information on ConvI2Ls used in address expressions. src/share/vm/opto/split_if.cpp test/compiler/6663854/Test6663854.java
19-02-2010
EVALUATION ChangeSet=http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/877a14af58e1,ChangeRequest=6663854
19-02-2010
EVALUATION This bug is similar to 6659207, as a ConvI2L with a constrained type is being split. One of the two new nodes is eliminated and the Phi input is replace with top. This bug is different in this case because do_split_if() is pushing a ConvI2L up through a Phi. The bandaid for 6659207 doesn't work because the original ConvI2L node is not initially directly referenced by a Phi. The fix for 6675699 should address this problem, however, this particular test case gives doubt as to whether a CastII with a control input would inhibit split-if from making dubious transformations.
19-03-2008