JDK-4927868 : deep recursion into PhaseIdealLoop::spinup: atg core dumped with fastdebug build
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.4.2_04,5.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,solaris_8
  • CPU: generic
  • Submitted: 2003-09-25
  • Updated: 2022-10-03
  • Resolved: 2003-12-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
1.4.2_05 05Fixed
Related Reports
Duplicate :  
Description
atg core dumped when running with 0921's fastdebug build in C2 mode on solaris x86

Test machine: jtg-lx50-2
# uname -a
SunOS jtg-lx50-2 5.9 Generic_112234-03 i86pc i386 i86pc
# /usr/j2se_b20/bin/java -server -version
java version "1.5.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta-b20)
Java HotSpot(TM) Server VM (build 20030921183238.robertg.baseline-fastdebug-debug, mixed mode)


JVM flags used: -server -XX:+DeoptimizeALot -XX:+SafepointALot 

Fastdebug build is get from
/net/balvenie.sfbay/export/imgr_home/archive/main/master/2003/20030921183238.robertg.baseline

How to reproduce the problem:
1. telnet jtg-lx50-2.sfbay
2. export JAVA_HOME=<jdk installation>
3. execute the script
/net/jtgb4u4c.sfbay/export/sail8/bigapps/tests/runatg.ksh -server -XX:+DeoptimizeALot -XX:+SafepointALot 

core file will be found under /bt/atg*/home within half an hour.

###@###.### 2003-09-24

# dbx /usr/j2se_b20/bin/java core
t@0 (l@7) terminated by signal SEGV (Segmentation Fault)
(dbx) where | more
  [1] Node::operator new(0x38, 0x3), at 0xdc66fad6
  [2] PhiNode::make_blank(0x885de14, 0x9c2e5e8), at 0xdc66874e
  [3] PhaseIdealLoop::spinup(0xd96fed88, 0xacfe974, 0x89d4990, 0x89d4abc, 0x885d
e14, 0x9c2e5e8, 0xd96fe830), at 0xdcc29ace

###@###.### 2003-09-24

Another snippet from stack trace:

  [1] PhaseIdealLoop::idom_no_update(0xd96aec88, 0x89fb5f0), at 0xdcc2b989
  [2] PhaseIdealLoop::spinup(0xd96aec88, 0x9d1f344, 0xac628c4, 0xac629f0, 0x89fb5f0, 0x89f8b28, 0xd96ae730), at 0xdcc29a24
  [3] PhaseIdealLoop::spinup(0xd96aec88, 0x9d1f344, 0xac628c4, 0xac629f0, 0xaa1bde0, 0x89f8b28, 0xd96ae730), at 0xdcc29b66
  [4] PhaseIdealLoop::spinup(0xd96aec88, 0x9d1f344, 0xac628c4, 0xac629f0, 0xaa1c354, 0x89f8b28, 0xd96ae730), at 0xdcc29b66
  [5] PhaseIdealLoop::spinup(0xd96aec88, 0x9d1f344, 0xac628c4, 0xac629f0, 0xaa1bde0, 0x89f8b28, 0xd96ae730), at 0xdcc29b66
......
......
  [98] PhaseIdealLoop::spinup(0xd96aec88, 0x9d1f344, 0xac628c4, 0xac629f0, 0xaa1c354, 0x89f8b28, 0xd96ae730), at 0xdcc29b66
  [99] PhaseIdealLoop::spinup(0xd96aec88, 0x9d1f344, 0xac628c4, 0xac629f0, 0xaa1bde0, 0x89f8b28, 0xd96ae730), at 0xdcc29b66
=>[100] PhaseIdealLoop::spinup(0xd96aec88, 0x9d1f344, 0xac628c4, 0xac629f0, 0xaa1c354, 0x89f8b28, 0xd96ae730), at 0xdcc29b66

###@###.### 2003-09-26

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.2_05 generic tiger-beta FIXED IN: 1.4.2_05 tiger-beta INTEGRATED IN: 1.4.2_05 tiger-b31 tiger-beta
14-06-2004

SUGGESTED FIX Do not do 'split-if' if irreducible loops are present. ###@###.### 2003-12-04 src/share/vm/opto/loopopts.cpp *** 650,655 **** --- 650,659 ---- if( n->is_Cmp() ) { if( C->unique() > 35000 ) return; // Method too big + // Do not do 'split-if' if irreducible loops are present. + if( _has_irreducible_loops ) + return; + Node *n_ctrl = get_ctrl(n); // Determine if the Node has inputs from some local Phi. // Returns the block to clone thru.
11-06-2004

EVALUATION The method spinup() goes into infinite recursion when 'true' and 'false' edges from the 'if' node (which we are splitting) lead to separate entries of an irreducible loop. ###@###.### 2003-12-04
04-12-2003

WORK AROUND Srinivas Ramakrishna wrote: Run program, passing the following flags to the java invocation: -Xbatch -XX:CICompilerCount=1 -XX:+PrintCompilation (You may skip -Xbatch flag to speed up program and use only -XX:+PrintCompilation flag if the problem is not reproduced with all these flags.) The combination of these will cause the (single) compiler thread to print information about the method it is compiling every time it compiles a method. When the compiler crashes because of stack overflow due to the deep recursion, the name of the last method in the output will be the method whose compilation caused the crash. You then have to add this method name to a file .hotspot_compiler in the directory from which the java invocation is done. If the method to exclude is A.B.C.foo::bar() then use a line of the form: exclude A/B/C/foo bar Then rerun again using the same options, and with this .hotspot_compiler file. If the compiler crashes again, you will get a new method name. Add new line "exclude D/E/classname methodname" to the .hotspot_compiler file and iterate as many times as is necessary to find all methods whose compilation exposes this vulnerability. Once you have collected all these methods and the crash goes away, you have the list of all methods. You can then run with this exclude file, but remove the -X options i outlined above and you have a very good chance of being able to stay up without running into the crash. Thanks, Ramki, for outlining the steps. The crash went away with atg.servlet.DynamoHttpServletRequest::getObjectParameter excluded. cat .hotspot_compiler exclude atg/servlet/DynamoHttpServletRequest getObjectParameter ###@###.### 2003-11-03
03-11-2003