Question about static Logger in OSGI

[cmhdave3266]

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[1]

To try this I follow these steps

1. Deploy code to AEM
2. Log into Felix console and stop our code bundle
3. Run jmap -dump:format=b,file=leak <pid> from the console
4. Run jhat -J-Xmx1024m leak
5. Open the browser to http://localhost:7000
6. 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?

[Jörg_Hoh · Accepted solution]

Hi,

I would recommend to discuss this topic on a sling mailinglist (see [1], I would recommend sling-user), as it's quite specific; there you probably get more expertise on that topic.

Kind regards,
Jörg

[1] http://sling.apache.org/project-information.html#mailing-lists