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.