Hi David First, I generally don’t use static references to loggers but rather instance references. Such that the references get cut once the instance is collected.
But then, what you are seeing is your custom class holding on to the logger and thus holding on to the logger’s class loader. This is not yours. There must be something else holding on to your class or, more often than not, to an instance of your class. In general this is the case if the class is held by a GC root. Situations where this may happen are ThreadLocals, extension of the Thread class not cleaned up or even threads still active after you stopped your bundle. You should not be looking at what your class references to but what is referencing to your classes. Regards Felix > Am 12.11.2014 um 02:03 schrieb David Collins <[email protected]>: > > 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?
