JDK-6589186 : 20070719212032.jrose.6337834 putback produces amd64 jvmg error: Bad immediate dominator info
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 5.0,7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_9,solaris_10
  • CPU: generic,sparc
  • Submitted: 2007-08-03
  • Updated: 2011-03-08
  • Resolved: 2011-03-08
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.
JDK 6 JDK 7 Other
6u10Fixed 7Fixed hs11Fixed
Related Reports
Duplicate :  
JDK-6599592 - xml/dsig failed in PIT 7.0 b20 with VM crashed on Solaris 10
Relates :  
JDK-6646019 - array subscript expressions become top() with -d64
Relates :  
JDK-6589823 - Error: meet not symmetric
Relates :  
JDK-6711100 - 64bit fastdebug server vm crashes with assert(_base == Int,"Not an Int")
Description
20070719212032.jrose.6337834 produces following error.
Previous putback: 20070718073059.nips.bug6579537-7 is okay.

hs_err file is attached, as well as doit script.
Run on amd64.

CompileTheWorld : Compiling all classes in /net/vmsqe.sfbay/export/backup/testbase/CompileTheWorld/jarfiles/ApacheJServ.jar
VM option '-ShowMessageBoxOnError'
VM option '+PrintCompilation'
VM option '+TracePartialPeeling'
VM option '+TraceSuperWord'
VM option '+TraceLoopUnswitching'
VM option '+CompileTheWorld'
VM option 'CompileTheWorldStartAt=43'

CompileTheWorld (43) : org/apache/jserv/Ajpv12InputStream
  1   b   org.apache.jserv.Ajpv12InputStream::<init> (6 bytes)
  2   b   org.apache.jserv.Ajpv12InputStream::<init> (7 bytes)
  3   b   org.apache.jserv.Ajpv12InputStream::readWord (34 bytes)
  4   b   org.apache.jserv.Ajpv12InputStream::readString (115 bytes)
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/loopnode.hpp:628
#
# An unexpected error has been detected by Java Runtime Environment:
#
#  Internal Error (/net/prt-sol-x64-2/tmp/PrtBuildDir/workspace/src/share/vm/opto/loopnode.hpp:628), pid=29595, tid=11
#  Error: assert(n != 0L,"Bad immediate dominator info.")
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (20070719212032.jrose.6337834-jvmg mixed mode solaris-amd64)
# An error report file with more information is saved as:
# /export1/nips/ctw/tmp2/hs_err_pid29595.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Current thread is 11
Dumping core ...
Abort
Comments
SUGGESTED FIX PRT webrev: http://prt-web.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/c2_baseline/2007/20071004144653.jrose.bugs0907/workspace/webrevs/webrev-2007.10.04/index.html
22-04-2008
EVALUATION if (pos_length_type != length_type) { Node* ccast = new (C, 2) CastIINode(length, pos_length_type); // %%% This control input (root) is lame. // %%% Can we push it down lower? ccast->set_req(0, root()); _gvn.set_type_bottom(ccast); record_for_igvn(ccast); length = ccast; } I'm looking at a bug we just got in and I'm suspicious of this code as the root cause. We're doing a split_if on a chunk of code involving this CastII and then die later because the dominance relationship between some defs and uses is broken. I can see that we end up with a clone that looks like this: 258 ConI === 0 [[ 1447 288 1165 407 416 431 1157 514 523 1517 1149 1140 1541 1540 1519 ]] #int:-1 1519 CastII === 0 258 [[ 1538 1537 ]] #int:0..1610612732:www !orig=[748] !jvms: Base64::decodeInternal @ bci:257 and ConstraintCastNode::Value returns top for this and I think there's where things begin to go wrong. Wouldn't it make more sense to put logic like this in LoadRangeNode::Ideal? That way we could put proper control on it. There are three purposes: 1. To enable a smart replace_in_map downstream of the allocation site, during parsing. 2. To improve the type everywhere of myNewArray.length. 3. To simplify object-sizing arithmetic in macro.cpp, especially on LP64. We get better code if we can avoid messing with sign bits on the array size. #1 can be preserved by building the cast node after the AllocateArray node. #2 can be preserved by your suggestion. #3 can be preserved by generating a new cast during macro expansion.
06-09-2007