Explanation for this behaviour of Permgen space

Question

I'm experimenting some problems with 2 separated web-apps that collaborates with each other in a project. After X number of deployments, I get the infamous "java.lang.OutOfMemoryError: PermGen space" error.

So I've been monitoring the PermGen space with VisualVM for a while, redeploying the apps continuously, to see what's happening.

And here the strange behaviour:

First I've redeployed more than 15 times the first app. The behaviour was as expected: the memory diagram was like a ladder increasing constantly, till it's near to the max size (67MB). In this point the memory is freed and returns to the initial level.

The same when i've redeployed the second application.

Then I've tried to redeploy both at the same time (tomcat does this sequentially), and the size of the "steps" of the ladder was bigger, but the behaviour was the same as in single deployments.

Then I've done the last test. I've redeployed both apps at the same time till the memory was very near to the limit, and then I've redeployed only one of the apps. And.. voilà: PermGen ERROR.

So.. what the hell is happening here?

The diagram of VisualVM. The first half (left) corresponds to the single deployments (applications 1 and 2). The second half (right) represents the point when I exceed the limit and get the error.

Thank you!

Answer 1

OP here.

I've been doing some research on this, and my conclusion is that it's more or less impossible to fully understand the behaviour of JVM related to the permgen space :)

At this point we all have read some topics about a possible memory leak related to the classloader. Definitions of classes remain unused, but stored in memory, till the permgen-limit is exceeded. That's theory. But it's very difficult to really know something about the origin of this leak, I mean if we are having a memory leak in our application caused by bad programming or not.

So finally my solution to this problem is to increase memory size and using some flags. That's something that I've read in some related topics here, in stackoverflow. It's what users use to do when they find the permgen error. I'm not sure if this is a solution or simply a way to forget this pain in the... ;)

In Catalina.sh (TOMCAT), I've added this line:

export CATALINA_OPTS="-Xms64m -Xmx512m -XX:PermSize=128m -XX:MaxPermSize=512m -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled"

Where:

-Xms64m sets minimum size of java heap memory to 64MB.

-Xmx512m sets maximum size of java heap memory to 512MB.

-XX:PermSize=128m sets initial size of permgen memory to 128MB.

-XX:MaxPermSize=512m sets maximum size of permgen memory to 512MB.

-XX:+UseConcMarkSweepGC : jvm will use Concurrent Mark Sweep Garbage Collector for the tenured generation of java heap

-XX:+CMSClassUnloadingEnabled : the Garbage Collector will sweep PermGen and remove classes which are no longer used.