All, we've been running into this issue where every time we deploy our code
to an AEM instance (5.6.1) the PermGen space increases which I can monitor
by attaching VisualVM. Now there are some good resources available by Frank
Kievet about this so I've been reading through this blog post:
http://frankkieviet.blogspot.ca/2006/10/how-to-fix-dreaded-permgen-space.html
To try this I follow these steps1) Deploy code to AEM2) Log into Felix
console and stop our code bundle3) Run jmap -dump:format=b,file=leak <pid>
from the console4) Run jhat -J-Xmx1024m leak5) Open the browser to
http://localhost:70006) Search for any instance of any of our classes
(which shouldn't appear if I'm understanding this correctly since we've
stopped the bundle)
I can do this and find 103 classes still loaded in the heap after the
bundle has been stopped. The large majority of these are static references
to a logger.
Here would be an example:
Static reference from org.company.cq.servlets.DataServlet.log (from class
org.company.cq.servlets.DataServlet) :
--> org.apache.sling.commons.log.internal.slf4j.SlingLogger@0x7bd99b160 (32
bytes) (??:)--> class
org.apache.sling.commons.log.internal.slf4j.SlingLogger (160 bytes) (??:)-->
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5@0x7b89b1ba8
(147 bytes) (field m_wiring:)-->
org.apache.felix.framework.BundleWiringImpl@0x7b8aa0c88 (171 bytes) (field
m_resolver:)--> org.apache.felix.framework.StatefulResolver@0x7b814a3d8 (97
bytes) (field m_revisions:)--> java.util.HashSet@0x7b8183ca8 (24 bytes)
(field map:)--> java.util.HashMap@0x7b8167ec0 (64 bytes) (field table:)-->
[Ljava.util.HashMap$Entry;@0x7b89b5178 (4112 bytes) (Element 74 of
[Ljava.util.HashMap$Entry;@0x7b89b5178:)-->
java.util.HashMap$Entry@0x7bd81c800 (44 bytes) (field key:)-->
org.apache.felix.framework.BundleRevisionImpl@0x7b88d0da0 (142 bytes)
(field m_wiring:)--> org.apache.felix.framework.BundleWiringImpl@0x7bd828730
(171 bytes) (field m_classLoader:)-->
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5@0x7bd75ca10
(147 bytes)
So it's somehow holding on to the classloader through SlingLogger. My
question is, how do we eliminate this problem?
