JDK-4697245 : 1.4.0_01 Server VM goes into an infinite loop that keeps allocating memory
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.4.0_01
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: unknown,sparc
  • Submitted: 2002-06-05
  • Updated: 2012-10-11
  • Resolved: 2002-06-27
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 Other
1.4.0_02 02Fixed 1.4.1Fixed
Related Reports
Relates :  
JDK-4414162 - Classloading: Exponential mem. use, and slow (in nested try/catch)
Relates :  
JDK-4702051 - Pathological jsr/ret constructs cause compiler crash
Description
When using the server VM of 1.4.0_01, the appserver 7 process suddenly goes into an infinite loop and its memory grows on and on. This behaviour occurs on both Win2k as well as Solaris. pstack analysis showed the following lwp as the possible source of the memory leak.

java version "1.4.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03)
Java HotSpot(TM) Server VM (build 1.4.0_01-b03, mixed mode)

-----------------  lwp# 20 / thread# 20  --------------------
 fdd4ce70 ciTypeFlow::Block*ciTypeFlow::Range::get_block_for(ciTypeFlow::JsrSet*,ciTypeFlow::CreateOption) (54d868, 5faf9c, 0, 0, 0, 0) + c0
 fdd5d58c GrowableArray<ciTypeFlow::Block*>*ciTypeFlow::Block::successors(ciByteCodeStream*,ciTypeFlow::StateVector*,ciTypeFlow::JsrSet*) (29aab2c, f13fef60, 5faf84, 5faf9c, 220, 8a) + 3a8
 fdd5cf64 void ciTypeFlow::flow_block(ciTypeFlow::Block*,ciTypeFlow::StateVector*,ciTypeFlow::JsrSet*) (3adb98, 36e1ab0, 1, 174d, 29aab2c, 0) + 840
 fddb75c8 void ciTypeFlow::flow_types() (3adb98, fe251400, 0, 26553c, 38, 4d4394) + 314
 fddb81c4 void ciTypeFlow::do_flow() (3adb98, f13ffd58, 3a92d0, ffffffff, b1, 3a9844) + c
 fdd93d50 ciTypeFlow*ciMethod::get_flow_analysis() (3a92d0, 3871a0, 20, 40, fe1d4000, 4d40e0) + dc
 fdd97fd4 Parse::Parse #Nvariant 1(JVMState*,ciMethod*,float) (f13ff194, 3871a0, 3a92d0, 41700000, fe1d4000, 387209) + 138
 fdd986dc JVMState*ParseGenerator::generate(JVMState*) (5faf74, 3871a0, 160, 4d4370, f13ff504, 0) + 98
 fde2a680 Compile::Compile #Nvariant 1(ciEnv*,ciScope*,ciMethod*,int,int,int,int) (5faf74, 6de98c, 0, 3a92d0, ffffffff, 1) + 8e4
 fde24c20 void C2Compiler::compile_method(ciEnv*,ciScope*,ciMethod*,int,int,int) (aae30, f13ffd58, 0, 3a92d0, ffffffff, 0) + 5c
 fde2567c void CompileBroker::invoke_compiler_on_method(CompileTask*) (c0, 0, ffffffff, fe1e2edc, fe20095c, 2a7728) + 660
 fdefd114 void CompileBroker::compiler_thread_loop() (2a6a18, 2a6a18, 8a278, 2a6f78, 343048, fde9165c) + 344
 fde91684 void JavaThread::run() (2a6a18, 0, 0, 0, 0, 0) + 278
 fde86fb4 _start   (2a6a18, f1400000, 0, 0, 0, 0) + 20
 fe8605fc _lwp_start (0, 0, 0, 0, 0, 0)
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.0_02 hopper-rc FIXED IN: 1.4.0_02 hopper-rc INTEGRATED IN: 1.4.0_02 hopper-rc
14-06-2004
WORK AROUND If you have control over the directory from which java is launched, you can instruct the compiler not to attempt to compile the particular method which tickles this bug: % cat <<_EOF >> .hotspot_compiler exclude _jasper/_com/_iplanet/_ias/_admin/_server/_gui/_jsp/_jato/_Index_jsp _jspService _EOF ------------ I could not reproduce the problem with the above workaround. When I removed the workaround, I was able to reproduce the problem. (I did see the following message which confirmed that I had put the .hotspot_compiler file in the correct directory) CompilerOracle: exclude _jasper/_com/_iplanet/_ias/_admin/_server/_gui/_jsp/_jato/_Index_jsp _jspServi ce ###@###.### 2002-06-24 ------------
24-06-2002
EVALUATION In order to analyze this bug I need a way to reproduce it. The simplest way to do this is probably to provide me with references to the *.jar files containing the various parts of the application, and the output of a failing run with -XX:+PrintCompilation turned on. Alternatively, I can probably extract this information from a core dump. Once I find out which method is putting TypeFlow into a spin, I can probably reproduce the problem and fix it. BTW, this bug is unfamiliar to me, at least so far. ###@###.### 2002-06-06 The method in question contains 5977 bytecodes, which is large but not unmanageable. It also contains 398 "jsr" instructions, to 55 distinct addresses (each with its own "ret" instruction). The server compiler eliminates "jsr/ret" pairs by cloning the "jsr" body at each call site. This again is not unmanageable, although a large subroutine with many call sites will expand to many copies. However, it shouldn't iterate forever. I have looked at all the "jsr" subroutines, and none of them are complex. None contain recursive "jsr" instructions. The solution may be to put a block-count cutout into ciTypeFlow, so that we can fail out of compiling very large methods (which would be likely to overflow the optimizer's node limit anyway). In order to analyze this further I need a complete list of jars so that I can run +CompileTheWorld on the offending method, with correct linkage of all its method calls. Note that this is a weaker requirement than running the app. itself. ###@###.### 2002-06-06 I have reproduced the erring run. I think it will eventually complete, given enough time and swap space. The problem is that many finally clauses have virtual calls, and also are governed by enclosing try/finally statements. Because a virtual call can throw exceptions (e.g., stack overflow, linker errors, NPE, etc.), the flow analyzer creates a new block to execute the cleanup of the enclosing finally clause, if the enclosed finally clause should throw. That is, the outer finally is cloned for each inner finally. If there are multiple nesting levels of try/finally (which it appears there are), we get a polynomial blow-up in basic block copies, with the exponent being the maximum nesting depth. Clearly, we need a simple bail-out to avoid compiling such methods. Also, the JSP compiler would be well-advised not to rely so heavily on try/finally, nor to generate such monolithic methods. ###@###.### 2002-06-07
07-06-2002