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
