Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

Question about static Logger in OSGI


Level 2

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:[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 (from class : --> (32 bytes) (??:) --> class (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?

0 Replies