What is the significance of PermGen space in java?
PermGen space is reserved for long-term objects - mostly Class
objects loaded by the ClassLoader
. PermGen will not be garbage collected except under very special circumstances (specifically, when the ClassLoader
that loaded those classes goes out of scope).
This is a garbage collection optimization - if objects that we don't expect to be garbage collected are stored separately, it compacts the space where the rest of the objects are stored, which leads to less work for the garbage collector.
The only thing you really need to know is that PermGen space is separate from the general heap and not affected by the -Xmx
VM parameter. If you have an application that loads lots of class definitions (like an application server or an IDE) then you can set the PermGen space size using the -XX:MaxPermSize
VM option.
The permanent generation holds meta-data describing user classes (classes that are not part of the Java language).
Applications with large code-base can fill up this segment of the heap which will cause java.lang.OutOfMemoryError: PermGen
. This is not affected by the -Xmx setting or how much memory you have on the machine. To set a new initial size, use -XX:PermSize=64m
. To set a maximum size, use -XX:MaxPermSize=128m
The PermGen is specific to VMs having generational garbage collection.
If you use, say, JRockit, the "significance of PermGen" is non-existent because JRockit doesn't have that concept.
It uses to be common, a few years ago, when the weird "out of PermGen space" errors started appearing and that nobody knew yet whose fault it was (Tomcat + Hibernate + Sun VM used to trigger this) to replace one of the component (nowadays the problems are understood, but years ago when they started cropping it was hardly possible to find any information on this). You could replace Tomcat with Resin or the Sun VM with JRockIt etc.
I think it's important to point out that PermGen are not part of the Java specs and only an implementation detail of (quite) some VMs.