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: 2024-05-06
  • 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 :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
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.

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

EVALUATION ChangeSet=http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/877a14af58e1,ChangeRequest=6663854

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.