Java.lang.OutOfMemoryError: PermGen space

From Resin 3.0

(Difference between revisions)
Jump to: navigation, search
Line 9: Line 9:
 
cause is that the JVM cannot garbage collect old classes that are replaced because there are  
 
cause is that the JVM cannot garbage collect old classes that are replaced because there are  
 
references to the old classes, as discussed in [[Classloader references]].
 
references to the old classes, as discussed in [[Classloader references]].
 +
 +
== MaxPermSize and debuggers (agents) ==
 +
 +
The JDK's permanent memory behaves differently depending on whether a debugging is enable, i.e. if there is an active agent.
 +
 +
If there is an active agent, the JDK can fail to collect permanent memory in some cases.  (Specifically, when some code introspects a class with a primitive array like, <code>byte[]</code> or <code>char[]</code>.)  This can cause the permanent space to run out, for example, when redeploying .war files.
 +
 +
From the JDK source code (systemDictionary.cpp):
 +
 +
    // Update: if a Java program cycles through a lot of class loaders         
 +
    // and the classes loaded by those class loaders have a lot of             
 +
    // primitive arrays, then the perm gen explodes in size. For now,         
 +
    // we revert back to Merlin (1.4.0) behavior and only save this           
 +
    // information if an agent is currently attached.

Revision as of 12:47, 5 April 2006


This error occurs when the JVM runs out of space in the permanent generation heap.

If the application(s) in the server use a large number of classes, the solution is to increase the value specified with -XX:MaxPermSize.

If the error occurs only after the redeployment and restart of new applications, then the likely cause is that the JVM cannot garbage collect old classes that are replaced because there are references to the old classes, as discussed in Classloader references.

MaxPermSize and debuggers (agents)

The JDK's permanent memory behaves differently depending on whether a debugging is enable, i.e. if there is an active agent.

If there is an active agent, the JDK can fail to collect permanent memory in some cases. (Specifically, when some code introspects a class with a primitive array like, byte[] or char[].) This can cause the permanent space to run out, for example, when redeploying .war files.

From the JDK source code (systemDictionary.cpp):

   // Update: if a Java program cycles through a lot of class loaders          
   // and the classes loaded by those class loaders have a lot of              
   // primitive arrays, then the perm gen explodes in size. For now,           
   // we revert back to Merlin (1.4.0) behavior and only save this             
   // information if an agent is currently attached.
Personal tools