[jira] [Closed] (FELIX-4418) Mark Bundle classloaders which should have been garbage collected

["Chetan Mehrotra (JIRA)" <ji...@apache.org>]

     [ 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)