java.lang.out of memory error permgen space

[saeediqbal1]

I saw that after modifying some of the seam-gen generated xhtml files jsf code and deploying it right after the other after 3-4 times. Is that normal?

[cja987]

This is a longstanding JVM bug. Increasing permgen space delays the inevitable a little bit, but switching to JRockit fixed it completely.

[pmuir]

Yup, I find jrockit avoids all the permgen stuff and decreases my JBoss AS start time to about 3/5ths. Apparently Java 6 also improves performance.

[quilleashm]

There are quite a few things that are non-bug related that can cause eventual OOM with permgen on a web container redeployment.

See more info here...

http://opensource.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669

I suspect the one that will most likely bite Seam users is the DriverManager "leak". I don't know what, if any, app servers handle these cases for you.

Having said all that there is a bug in the Sun Server JVM that causes the permgen size to be larger than it should be but it doesn't leak over time.

See: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4957990

There was a ClassLoader leak bug once upon a time but this have been fixed and backported to 1.4 and 1.5

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5033614

[saeediqbal1]

I'm glad I shared this information with you guys. Is it safe to use JRockit with Seam?

Thanks.

[alexeinov]

"saeediqbal1" wrote:
Is it safe to use JRockit with Seam?Thanks.

What is "safe"?

I'm using JRockit with Seam, it works. It cannot solve memory leak problems that exist in your application, container or libs though.

JRockit survives longer if a ClassLoader is leaking because it holds all allocated objects in the same heap. The dreaded PermGen error does not occure in it since there's no separate PermGen.

Sun's JVM has two allocation areas: heap and non-heap, PermGen is a section of non-heap area. When a ClassLoader leaks, PermGen runs out of megabytes quickly, and here you are: Out Of Memory PermGen error.

When a ClassLoader leaks in JRockit, it leaks in a main heap allocation area, which is much bigger, hence it takes longer time to exhaust it.

It's not safe to run leaking code, and JRockit does not make it safer, though you get more time between crashes.