[description pasted from support case]

After many redeploys of applications, we have JVMs failing with "OutOfMemory perm gen" errors. We have installed the JBoss profiler, and taken heap dumps when the JVM is close to failing (after deploying and undeploying an application ~30 times). By searching for classloaders that have "com.XXX" classes loaded, and then searching for paths to heap roots from those classloaders, we have identified what we believe to be a leak associated with instances of org/jboss/mx/loading/UnifiedClassLoader3. Specifically, we see strong paths to heap roots like the following:

found a path to the target: 26093 (depth: 5)
0 0 Heap root
26636 0 Instance: Lcom/sun/jmx/remote/internal/ArrayNotificationBuffer;
124809 0 Instance: Lcom/sun/jmx/remote/internal/ArrayQueue;
160611 0 Instance: [Ljava/lang/Object;
161523 0 Instance: Lcom/sun/jmx/remote/internal/ArrayNotificationBuffer$NamedNotification;
217357 0 Instance: Ljavax/management/Notification;
26093 26106 Instance: Lorg/jboss/mx/loading/UnifiedClassLoader3;

So, even though our application is undeployed, strong paths from their classloaders to heap roots exist.

Specifically, it appears that this might be related to registering the classloader to receive JMX notifications and not unregistering it on an application undeploy. Please advise on what you think is the best strategy for resolving this problem.