Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: neutral (hermes.apache.org: 64.14.202.141 is neither permitted
 nor denied by domain of dain@iq80.com)
Mime-Version: 1.0 (Apple Message framework v730)
In-Reply-To: <CB873ABF-2F38-48D7-94F4-9F32782EE6CE@iq80.com>
References: <7DF6BC2D-6B08-42E1-A997-B529B4D1DC66@iq80.com>
 <CB873ABF-2F38-48D7-94F4-9F32782EE6CE@iq80.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <868F5445-AEB2-4FEB-A0AA-33334FBE9C4C@iq80.com>
Content-Transfer-Encoding: 7bit
From: Dain Sundstrom <dain@iq80.com>
Subject: Re: Memory leaks
Date: Mon, 6 Jun 2005 08:33:32 -0700
To: dev@geronimo.apache.org

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