JDK-4390238 : JDK1.3 throws OutOfMemoryError when trying to allocate PermGeneration space
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.3.0,1.3.0_01,1.3.1
  • Priority: P2
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: solaris_7,solaris_8,windows_nt
  • CPU: x86,sparc
  • Submitted: 2000-11-17
  • Updated: 2002-06-11
  • Resolved: 2002-06-11
Related Reports
Relates :  
JDK-4484290 - JDK1.3.1: WebLogic6.1 appserver dies with OutOfMemoryError
Relates :  
JDK-4523683 - java.lang.OutOfMemoryError thrown with server -Xcomp in 1.3.1_02
Relates :  
JDK-4504200 - JVM givess error: Exception in thread "CompileThread0" java.lang.OutOfMemoryErro
Description
When Weblogic Server (WLS) loads more than ~400 EJBs, the HotSpot VM throws an OutOfMemoryError exception. This occurs even though there appears to be lots of memory available; in our scenario, there was over 460 mb of memory available
based on a call to Runtime.getRuntime().freeMemory(). Loading large number
of EJBs was possible with previous versions of the VM.

The HotSpot VM was throwing the OutOfMemoryError when trying to allocate
PermGeneration space. It appears that the HotSpot VM has different sections
of memory. The permanent generation section (used for classes, methods, 
symbols ??) has an initial size of 1 mb and a max size of 32 mb.

Fortunately, this limit can be raised at runtime using the

        java -server  -XX:MaxPermSize=65536K

command line argument. The above command raises the MaxPermSize to 64 mb. With this limit, we were able to load additional ejbs.

However, the -XX options are not supported, and ISVs/Customers are wary about using XX options.

==============
Note that currently, increasing the MaxPermSize only delays the failure.

neal.gafter@Eng 2001-05-22
Comments
WORK AROUND Use the -client VM parameter instead of -server. Increase the MaxPermSize value by using the command line flag: -XX:MaxPermSize=128M See http://java.sun.com/docs/hotspot/VMOptions.html
11-06-2004
EVALUATION Changing to RFE from bug as the customer issue is a request to stabilize / make official the current -XX option which yields the desired result. lew.yobs@Eng 2001-02-16 Changing from RFE to Bug because throwing an OutOfMemoryError when we are not out of memory is not correct. The fact that the customer suggests a particular resolution to the problem (which indidentally does not resolve the problem, only defers it) doesn't make it anything less than a bug, and a serious one at that. neal.gafter@Eng 2001-04-19 Try as a workaround using the -client VM parameter instead of -server. neal.gafter@Eng 2001-05-22 I need a testcase or access to the application that is exhibiting this problem. There have been many reports of OOM but no testcase to work with. I will be closing this bug next week if I don't hear anything. ###@###.### 2001-08-24 This problem can be reproduced consistently by running the J2EE compatibility test suite (CTS) aginst J2EE RI 1.3 You will need to contact ###@###.### (manager) and ###@###.### (engr) for more information on how to setup and run CTS. You can also look at the bug 4412393. We workaround the problem by increasing the MaxPermSize manually. ###@###.### 2001-08-24 Please do not close this bug until we've checked for the same problem in 1.4. If a reproducable test case is found, please forward to me! ###@###.### 2002-02-18 Please see the workaround suggested. You have to tune the -XX:MaxPermSize value for your particular application. By default for server compiler its 64M and 32M for the client compiler. ###@###.### 2002-05-29
29-05-2002
PUBLIC COMMENTS In 1.3.1 for server JVM the default MaxPermSize is doubled to 64M. lew.yobs@Eng 2001-08-07
07-08-2001