Problem with PermGen Space

[ulix83]

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?

The question associated tieh Eclipse: 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, in Eclipse, is there a tool that allow me to do this
automatically?).

Thank you everybody for your attention!

[Tolls]

PermGen is the space used to store the classes.
It isn't part of the regular heap so doesn't go through the garbage collection cycle (as such).

Use -XX:MaxPermSize to set it (I think that's the switch).

[ulix83]

Thank you for your answer! I will do it instantly.

So, from your answer I understand that it is not useful to set, in a finally block, all the variables at null. Isn't it?

[Tolls]

It is never (except in one or two really really specific cases) necessary to set a variable to null in order to try and get something garbage collected. Once it's out of scope it is eligible.

Though that has nothing to do with PermGen.

[ulix83]

Ok, thank you again for your answer.
I am using visualVM and jmap+jhat: I did realize what you wrote, because the heap space is correctly cleaned by the GC while the permgen space only grows and never decrease.
I did set -XX:MaxPermSize to 512, and the problem seems to be fixed.
But I am afraid that, as permgen space does not seem to decrease, the problem could raise again, that is that it's just postponed.
What do you think about it? Have you something to suggest me?

[Tolls]

PermGen will increase simply because, as a program runs, more classes tend to get loaded up. Eventually you will have loaded all the classes required by your program and it will then be steady.

[ulix83]

Ok, thank you!

I am now using JVisualVM for trying to understand if are there programming errors in my code that do not prevent my application to work fine but that causes too memory usage. But: as I perform a HeadDump I can find, for example, 203489 instances of java.lang.String. Is there a way to know in which classes/object are they instantiated (for String instances, but also for other classes as ArrayList, ...) ?

[Tolls]

I don't know if the one you're using shows a graph of the largest objects, but Eclipse MAT does. That's the best way of spotting protential problem areas. SImply looking at raw numbers (like number of String objects) doesn't tend to point you in the right direction.

Also, there's no point doing all this if you haven't encountered a problem yet. To find out if there is a problem the best technique is to load test your program somehow and see if it falls over. There are also memory monitors you can use that will attach to the JVM and allow you to watch a graph as the memory is used and then garbage collected. It's like watching a (very slow) heart beat.
:)

[ulix83]

Thanks for your advices.
In particular, I did not know Eclipse MAT, and it really works fine!