felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chetan Mehrotra (JIRA)" <j...@apache.org>
Subject [jira] [Closed] (FELIX-4418) Mark Bundle classloaders which should have been garbage collected
Date Thu, 06 Feb 2014 09:42:09 GMT

     [ 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 

from   org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5 cl 

> 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

View raw message