wood burning stoves*
The moose likes JBoss/WildFly and the fly likes PerGen Space Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Products » JBoss/WildFly
Bookmark "PerGen Space" Watch "PerGen Space" New topic
Author

PerGen Space

John Ulix
Greenhorn

Joined: Sep 29, 2010
Posts: 5
Hello everybody
I have a problem with JBoss, that is: I did deploy a project and after a
few hours of execution (without new deploy) I have "Java.lang.OutOfMemoryError: PermGen space".
Why garbgage collector does not succeed in deallocate memory? What may be the problem?

Do you think that it could be a good idea to set to null all the variables of all the methods of all
the classes of the project in a finally block? (in this case, is there a tool that allow me to do this
automatically?).

Thank you everybody for your attention!
Jason Cone
Greenhorn

Joined: Jul 21, 2004
Posts: 25
While it's possible that you are legitimately running out of PermGen space and need to increase it, this error usually indicates some sort of memory leak, in my experience.

Start by bumping up your PermGen space to see if the problem persists, even with a larger PermGen (-XX:PermGen and -XX:MaxPermSize). If you still run into the error, start looking for your leak. I suggest using jmap to generate details about the contents of PermGen. You may see something obvious. For example, I ran into this problem a few months ago. Running jmap showed that PermGen was filling up with GroovyClassLoader instances. Each one was listed as having the JBoss UCL as its parent classloader, and each one was marked as "dead," but they weren't being collected. Turns out it was a "classloader leak." When the GroovyClassLoader was constructed in our code, we were passing it the parent classloader (i.e. the JBoss UCL). This resulted in JBoss storing a reference to each GroovyClassLoader that was constructed with the JBoss UCL as its parent. Changing our code to construct the GroovClassLoader instances without a parent classloader solved the problem.

If you have a leak, it's probably something similar. Somewhere, a reference to your objects is being retained, so they're not being collected. Profiling should lead you to the answer. Good luck!
John Ulix
Greenhorn

Joined: Sep 29, 2010
Posts: 5
Thank you for your answer, I will try to do what you suggest!
John Ulix
Greenhorn

Joined: Sep 29, 2010
Posts: 5
Hello, I am usingo local the instrument suggested by you, and I can see that the heap space is rightly cleaned by GC, while the permgen space only gorws and never decreases. I did run jmap -dump:file=d.dump on my pc, where the applications runs on locahost. On the computer where the application is finally deployed I have, with the same command, the error:

"not enough storage is available to process this command"

Did it ever happen to you? 21 GB are free on the HD!

Thank you again

Jason Cone
Greenhorn

Joined: Jul 21, 2004
Posts: 25
No, I didn't run into that issue. I'd try:

jmap -permstat <pid>

Where <pid> is your process I.D. You're more interested in the permanent generation info than the heap info.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: PerGen Space
 
Similar Threads
How to write and deploy a complete EJB Application
Deploying problem on eclipse
Eclipse + Maven + Tomcat
404 Error in Spring MVC
jobss