You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Dain Sundstrom <da...@iq80.com> on 2005/06/05 03:46:57 UTC
Memory leaks
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
Re: Memory leaks
Posted by Dain Sundstrom <da...@iq80.com>.
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
>>
>>
>
Re: Memory leaks
Posted by Dain Sundstrom <da...@iq80.com>.
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
>
>