[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] ClassLoader leak caused by EventManager's EventThread creation


Can you file a bug on this?

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the
OSGi Alliance

office: +1 386 848 1781
mobile: +1 386 848 3788

From: Andy Wilkinson <andy.wilkinson@xxxxxxxxxxxxxxxx>
To: <equinox-dev@xxxxxxxxxxx>
Date: 2009/05/06 09:22
Subject: [equinox-dev] ClassLoader leak caused by EventManager's EventThread        creation
Sent by: equinox-dev-bounces@xxxxxxxxxxx


I've been looking into a PermGen leak and have identified what looks to
be an undesirable side-effect of
org.eclipse.osgi.framework.eventmgr.EventManager's creation of an
EventThread instance. In my particular situation the EventManager
instance is MRUBundleFileList's bundleFileCloserManager. I'm running on

When the EventThread is lazily created, it gets its context class loader
from the current thread. In my situation it's a call from a non-Equinox
owned thread that's triggered the lazy creation of the EventThread
instance. In this case at least, it doesn't seem right for this
Equinox-owned thread to be holding a reference to this foregin class
loader, particularly as it's not easy to update the EventThread's
context classloader in application code. The reference to the
classloader leads to a PermGen leak as the classloader doesn't become
eligible for garbage collection.

With the caveat that I don't know if there is some expectation about
what the event thread's context class loader should be, I wonder if it
would be better if EventManager was updated to explicitly set an
EventThread's context class loader, possibly to Equinox's classloader,
i.e. EventManager.class.getClassLoader()?

equinox-dev mailing list