United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6663854 assert(n != __null,"Bad immediate dominator info.") in C2 with -Xcomp
JDK-6663854 : assert(n != __null,"Bad immediate dominator info.") in C2 with -Xcomp

Details
Type:
Bug
Submit Date:
2008-02-15
Status:
Resolved
Updated Date:
2012-02-01
Project Name:
JDK
Resolved Date:
2010-03-10
Component:
hotspot
OS:
linux_suse_sles_10,linux,solaris_10
Sub-Component:
compiler
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
6u6,6u10,6u17
Fixed Versions:
hs17 (b11)

Related Reports
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Duplicate:
Relates:
Relates:
Relates:

Sub Tasks

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

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.
                                     
2008-03-19
EVALUATION

ChangeSet=http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/877a14af58e1,ChangeRequest=6663854
                                     
2010-02-19
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
                                     
2010-02-19



Hardware and Software, Engineered to Work Together