Comments on: OutOfMemory PermGen with Sun JDK

By: online bible

online bible — Thu, 04 Mar 2010 00:17:08 +0000

I find it crazy that this is still a problem.

By: samaxes » Classloader leaks and PermGen space

samaxes » Classloader leaks and PermGen space — Tue, 22 Apr 2008 23:46:08 +0000

[...] passing command line arguments to the JVM or changing the size of the PermGen space, others end up recommending using a VM from BEA or IBM, all without [...]

By: tOMPSON’s blog » Blog Archive » OutOfMemory PermGen with Sun JDK reviewed again

Thu, 11 Oct 2007 07:42:33 +0000

[...] response to my post about OutOfMemory PermGen errors in Tomcat with Sun JDK brought up some very interessting things. I learned a lot from Frank Kieviet’s blog about [...]

By: tompson

tompson — Wed, 03 Oct 2007 07:57:01 +0000

I think I will run the test again with Tomcat 6.x as soon as I get a time frame

By: Developer’s Blog » Blog Archive » java.lang.OutOfMemoryError: PermGen space

Tue, 02 Oct 2007 06:08:18 +0000

[...] java.lang.OutOfMemoryError: PermGen space [...]

By: anjan bacchu

anjan bacchu — Mon, 01 Oct 2007 22:17:33 +0000

hi there,

tomcat 6.x fixed this bug (among others). try tomcat 6 and let us know if that worked.

BR,
~A

By: siddii

siddii — Mon, 01 Oct 2007 22:08:28 +0000

Here is something I discovered a while ago which you might find useful
http://blogs.boxysystems.com/2007/4/11/tomcat-v5-0-28-memory-leak-exposed

By: bwtaylor

bwtaylor — Mon, 01 Oct 2007 22:05:15 +0000

This is a memory leak issue. It affects all app servers. It is caused by references from objects outside the webapp classloader back into the classes loaded by the webapp. One such reference prevents that class from being GC’d, which prevents the classloader from being GC’d, which prevents all classes under it from being GC’d.

These references fall into two types: a) classes that register with system classes (e.g. a JDBC driver in your webapp that registers with the system DriverManager) and b) ThreadLocals held by the connection pool. The ones in class a) are usually fixable by running cleanup code when your webapp context is destroyed. The ones in b) are much harder and this basically represents a bug/feature in both the ThreadLocal class and the fact that app servers don’t have a convenient way to dedicate Threads to webapps and recreate them as part of reloading the web app. Careful use of ThreadLocals can alleviate this, but finding offenders is pretty hard, even with a good profiler.

By: ozh

ozh — Mon, 01 Oct 2007 20:01:56 +0000

This problem is not only for the tomcat.
I am running an application on the Apache Geronimo (jetty based) with JDK 5, after one or two days, jvm gives same error.

By: stoney

stoney — Sun, 30 Sep 2007 06:31:25 +0000

the only thing that prevented me from experimenting with classloader leaks was the missing support for tracing classes in jhat. Fortunately, from JDK7b2 this issue will be fixed, as can be seen in SUN's bug tracking system. Another interesting thing about jhat I tumbled over, is the possibility to create custom reports by using jhat's OQL interface. A. Sundararajan's blog has some really good posts on that topic: *) querying java heap with OQL *) jhat's javascript interface