This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
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
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!
Joined: Sep 29, 2010
Thank you for your answer, I will try to do what you suggest!
Joined: Sep 29, 2010
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
Joined: Jul 21, 2004
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.