- java.lang.OutOfMemoryError: PermGen space
In this article, we will discuss:
- Java Objects vs Java Classes
- PermGen Collection[2]
- Class unloading
- How to find the classes allocated in PermGen?
- How to enable class unloading for CMS?
Note that this article is mainly based on Jon's excellent article[1].
Java Objects vs Java Classes
PermGen Collector
The internal representation of a Java object and an internal representation of a Java class are very similar. From now on, we use Java objects and Java classes to refer to their internal representations. The Java objects and Java classes are similar to the extent that during a garbage collection both are viewed just as objects and are collected in exactly the same way.
Besides its basic fields, Java class also include the following:
- Methods of a class (including the bytecodes)
- Names of the classes (in the form of an object that points to a string also in the permanent generation)
- Constant pool information (data read from the class file, see chapter 4 of the JVM specification for all the details).
- Object arrays and type arrays associated with a class (e.g., an object array containing references to methods).
- Internal objects created by the JVM (java/lang/Object or java/lang/exception for instance)
- Information used for optimization by the compilers (JITs)
Class Loading/Unloading
Back in old days, most classes were mostly static and custom class loaders were rarely used. Then class unloading may not be necessary. However, things have changed and sometimes you could run into the following message:
- java.lang.OutOfMemoryError: PermGen space
In this case, there are at least two options:
- Increasing the size of PermGen
- Enabling class unloading
Increasing the Size of PermGen
Sometimes there is a legitimate need to increase PermGen size by setting the following options:
- -XX:PermSize=384m -XX:MaxPermSize=384m
However, before you do that, you may want to find out what Java classes were allocated in PermGen by running
- jmap -permstat
This is supported in JDK5 and later on both Solaris and Linux.
Enabling Class Unloading
By default, most HosSpot Garbage Collectors do class unloading except CMS collector[2] (enabled by -XX:+UseConcMarkSweepGC).
If you use CMS collector and run into PermGen's out-of-memory error, you could consider enabling class unloading by setting:
- -XX:+CMSClassUnloadingEnabled
- -XX:+CMSPermGenSweepingEnabled
Depending on the release you may have, earlier versions (i.e., Java 6 Update 3 or earlier) require you to set both options. However, in later releases you only need to specify:
- -XX:+CMSClassUnloadingEnabled
The following are the cases that you want to enable class unloading in CMS collectors:
- If your application is using multiple class loaders and/or reflection, you may need to enable collecting of garbage in permanent space.
- Objects in permanent space may have references to normal old space thus even if permanent space is not full itself, references from perm to old space may keep some dead objects unreachable for CMS if class unloading is not enabled.
- Lots of redeployment may pressure PermGen space
- A class and it's classloader have to both be unreachable in order for them to be unloaded. A class X with classloader A and the same class X with classloader B will result in two distinct objects (klassses) in the permanent generation.
References
- Understanding GC pauses in JVM, HotSpot's CMS collector.
- Understanding Garbage Collection
- Presenting the Permanent Generation
- Diagnosing Java.lang.OutOfMemoryError
- A Case Study of java.lang.OutOfMemoryError: GC overhead limit exceeded
- Understanding Garbage Collector Output of Hotspot VM
- Java HotSpot VM Options
- Eight flavors of java.lang.OutOfMemoryError
No comments:
Post a Comment