For us the cause was frequently third party libraries doing silly things like starting non-daemon threads in static scope that cannot be shut down, which keeps references to the old classloader. So every time that bundle is replaced the PermGen climbs and can never be reclaimed.
Among others, the AWS SDK was a big culprit in our apps. After spending days in the heap analyzer trying to track everything down I finally said screw it, and now we're back to forcing a full restart w/ cache wipe when we deploy code updates. I don't think that hot-deployment is worth the time it will take you unless you don't use any third party code, and even then you will regularly spend hours in the profiler trying to figure out what's hanging onto the old classloader with the latest code update. On Tue, Mar 11, 2014 at 1:46 PM, Guillaume Nodet <[email protected]> wrote: > This could also be caused by bad bundles that don't clean things correctly > when stopped. > > > 2014-03-11 19:21 GMT+01:00 Henryk Konsek <[email protected]>: > > Hi, >> >> > If >> > this issue exists, can we not be safe in planning to do updates like >> that? >> >> Oracle JVM keeps classes forever until instructed otherwise. Try to >> enable garbage collector on PermGen memory space. >> >> -XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled >> -XX:+CMSClassUnloadingEnabled >> >> Cheers. >> >> -- >> Henryk Konsek >> http://henryk-konsek.blogspot.com >> > >
