Re: [equinox-dev] ClassLoader leak caused by EventManager's EventThread

[BJ Hargrave <hargrave@xxxxxxxxxx>]

Andy,

Can you file a bug on this?
--

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

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

---

Hi,

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
3.5.0.v20090311-1300.

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()?

Regards,
Andy
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev