Memory leaks

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Memory leaks

Dain Sundstrom
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


Reply | Threaded
Open this post in threaded view
|

Re: Memory leaks

Dain Sundstrom
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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Memory leaks

Dain Sundstrom
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
>>
>>
>