[
https://issues.apache.org/jira/browse/FELIX-4418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra closed FELIX-4418.
----------------------------------
Resolution: Not A Problem
Framework currently marks the {{m_isDisposed}} to true for the wiring
associated with the classloader. So running following query in VisualVM OQL
yields the leaking classloaders
{noformat}
select
toHtml(cl)
from org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5 cl
where
cl.m_wiring.m_isDisposed==true
{noformat}
> Mark Bundle classloaders which should have been garbage collected
> -----------------------------------------------------------------
>
> Key: FELIX-4418
> URL: https://issues.apache.org/jira/browse/FELIX-4418
> Project: Felix
> Issue Type: Wish
> Components: Framework
> Reporter: Chetan Mehrotra
> Priority: Minor
>
> With OSgi its possible that a bundle gets refreshed/updated and thus creates
> new classloaders. In ideal case the old classloaders should get garbage
> collected and not be referred. However at times it happens that such
> classloaders remain alive because proper cleanup on bundle decativation is
> not performed. This leads to classloaders leak.
> As framework knows when a BundleClassLoader becomes stale and a candidate for
> GC it can mark such classloaders with some flag. This would help later in
> analyzing the Heap dumps as one can query for such classloaders based on that
> flag. This apprach has been used for example in Resin [1] where it marks such
> classloaders with {{com.caucho.loader.ZombieClassLoaderMarker}}
> We are using another approach with SLING-3359 where we have a bundle which
> registers PhantomReference against the bundle classloaders and then
> determines which classloader should have been garbage collected and hence are
> leak suspects
> [1]
> http://java.jiderhamn.se/2011/12/11/classloader-leaks-i-how-to-find-classloader-leaks-with-eclipse-memory-analyser-mat/
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
