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]
