Perm space is garbage collected when the classloader that loaded the
class files is garbage collected. And this happens not only during hot
redeploys. This is info is per JVM spec.
Serge.
Scott Russell wrote:
This is a common issue that has also been noted on the hibernate forums, among
others.
The JVM allocates a certain amount of its total memory to 3 basic areas:
i) Young generation (YoungGen) - this is for objects that only live for a few
hundred milliseconds to a couple of seconds, at the most.
ii) Old generation (OldGen) - this is for longer living objects - when the
garbage collector does a sweep over the YoungGen, any unclaimable objects are
moved to the OldGen area. When the OldGen area starts to fill up, the garbage
collector will occasionally do a full GC, which also attempts to reclaim any
memory it can from the OldGen as well.
iii) Permanent Generation (PermGen) - This is for permanent memory allcoation,
and is used to store mainly java class information.
PermGen space is NOT garbage collected, so the more classes you load, the more
it fills up. For most applications this hardly causes any problems, but when
you have applications that dynamically create java classes, you have a
situation where over time the PermGen space will start to use up more memory
than it would have for all statically compiled classes.
Moreover, PermGen space very often is not cleaned out properly during web
application reload, with some certain notable offenders (Commons Logging,
java.sql.DriverManager), holding static references to their own class files,
thus preventing class unloading. So the memory usage just goes up and up with
subsequent reloads.
Some frameworks/java libraries that dynamically create java class files (that
I know of) include:
i) JSP
ii) JDK Proxy (used by Spring and others)
iii) CGLib (used by Spring and Hibernate and some JDO implementations),
iv) Javassist (used by JBoss and Tapestry)
So the problem here is that for a large web application (such as I have)
consisting of Tapestry pages, with Spring services, and Hibernate back-end,
you have a requirement for more than the default PermGen memory in your
servlet container. The good news, though, is that provided you haven't done
something irresponsible like disable page caching in production, there IS an
upper limit on the classes that will be dynamically generated.
You can increase PermGen size by adding this to your jvm parameters:
-XX:MaxPermSize=??M (where ?? is some memory value like 64 or 128)
If you want to see the garbage collector in action, add this to your jvm
parameters:
-Xloggc:gc.out -XX:+PrintGCDetails
Lastly, on the subject of webapp reload. The servlet specs do not require a
servlet container to support webapp reload. So don't treat it as a right. I
only use the reload feature in development only, or on simple webapps only in
production. But if I'm updating a large webapp that uses
Tapestry+Spring+Hibernate, I pick a quiet time of the day (or night) and
restart Tomcat. It causes so much less hassle.
regards,
Scott
On Tue 29 November 2005 01:24, Martin Strand wrote:
I keep getting this error from Tomcat:
java.lang.OutOfMemoryError: PermGen space
It seems to happen randomly. I read this article on TSS:
http://theserverside.com/news/thread.tss?thread_id=36743
"The permanent generation is special because it holds meta-data describing
user classes (classes that are not part of the Java language)."
As I understand it, the article implies that this error can occur when you
use a large number of classes. I've got less than 50 classes right now for
all components, pages and business logic but I'm still getting that error.
Perhaps this PermGen space error is because of a large number of enhanced
classes? Or perhaps "hot code replace" leaves a number of old replaced
classes hogging the PermGen space?
Anybody else experiencing this?
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
