In the eden generation, objects are very short lived and garbage collection is swift and often.
The young generation consists of objects that survived the eden generation (or was pushed down to young because the eden generation was full at the time of allocation), garbage collection in the young generation is less frequent but still happens at quite regular intervals (provided that your application actually does something and allocates objects every now and then).
The old generation, well, you figured it. It contains objects that survived the young generation, or have been pushed down, and garbage collection is even less infrequent but can still happen.
And finally, the permanent generation. This is for objects that the virtual machine has decided to endorse with eternal life – which is precicely the core of the problem. Objects in the permanent generation are never garbage collected; that is, under normal circumstances when the jvm is started with normal command line parameters.
So what happens when you redeploy your web application is, that your WAR file is unpacked and its class files loaded into the jvm. And here’s the thing: almost always ends up in the permanent generation… Because, seriously, who wants to garbage collect their classes?!? Well, apparently application servers do, and here’s how we make that happen for JBoss, but the same configuration is applicable to other application servers, adding the following parameters to the bin/run.conf file at JAVA_OPTS line:
-XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=128m
Consider eventually tuning the MaxPermSize=128m part to fit your needs…