geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: Memory leaks
Date Mon, 06 Jun 2005 15:33:32 GMT
I fixed most of the class loader memory leaks.  There is still slow  
leak in cglib which I think will be fixed quickly.

For anyone interested in the problem of garbage collecting class  
loaders, I suggest a wonderful series of articles written by Attila  
Szegedi (http://www.szegedi.org/).  The most helpful for me was the  
third part (http://www.szegedi.org/articles/memleak3.html) which  
covers memory leaks in java.io.ObjectStreamClass.  This VM bug was  
causing OutOfMemoryErrors for us when deploying lots of applications.

-dain

On Jun 4, 2005, at 7:13 PM, Dain Sundstrom wrote:

> After poking around the commons logging 1.0.4 code, it looks like I  
> can explicitly release a class loader from the hashtable, so I'm  
> going to take a crack at getting our class loaders to GC.
>
> -dain
>
> On Jun 4, 2005, at 6:46 PM, Dain Sundstrom wrote:
>
>
>> The other day I started to see OutOfMemory errors, so after a few  
>> hours of poking around with YourKit, I found the two big leaks.
>>
>> The first one I found was caused by the GBean reference object  
>> registering a listener with the lifecycle monitor and never  
>> unregistering it.  Since the reference holds on the the  
>> GBeanInstance we never could collect a GBeanInstance that had a  
>> reference (most do).  This doesn't mean we were leaking instance  
>> of the actual service objects, but the GBeanInstance object does  
>> hold on to a lot of data.
>>
>> The second leak we have is a leak of class loaders due to the  
>> following two causes:
>>
>> 1) Commons logging 1.0.4
>> The LogFactory retains a hard reference to the class loader.  I  
>> believe this has been addressed in the next version which is  
>> version just in alpha now.
>>
>> 2) Context class loader of a pooled thread
>> We need to clear the context class loader before putting threads  
>> back in a pool.  The context class loader should always be cleared  
>> after being set in a try/finally block, but in some cases they are  
>> not.  BTW, this is not always a pool, the sun orb keeps a hard  
>> reference to a thread it uses for reading from a socket.
>>
>> I don't fix the class loader leak right now (due to commons  
>> logging), but we should at least start to clear the context when  
>> reinsert a into a pool.
>>
>> -dain
>>
>>
>


Mime
View raw message