[ mx4j-Bugs-985335 ] Dynamically loaded classes are not garbage collected.

Bugs item #985335, was opened at 2004-07-05 21:02
Message generated for change (Settings changed) made by anoripi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=450647&aid=985335&group_id=47745

Category: JMX implementation
Group: Release 2.0.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Trustin Lee (anoripi)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Dynamically loaded classes are not garbage collected.

Initial Comment:
I made a small JMX microkernel which provides dynamic 
class reloading feature.

I registered HTTPAdaptor MBean and unregistered it, 
and then created a new class loader and registered it 
again, ...., and then I gets OutOfMemoryError.

At first, I thought it is my classloader's problem, but it 
seems to be working very fine with other MBean JARs.

I ran MX4J with debugger, and some WeakHashMap is 
holding already unregistered MBeans' classes.  I think 
HTTPAdaptor MBean has some coupling with MX4J core.

Any ideas?


----------------------------------------------------------------------

Comment By: Trustin Lee (anoripi)
Date: 2004-07-06 11:18

Message:
Logged In: YES 
user_id=65318

I tried Sun JMX-RI, and everything seems to be working fine.  
It looks like MX4J core bug.

----------------------------------------------------------------------

Comment By: Trustin Lee (anoripi)
Date: 2004-07-06 10:22

Message:
Logged In: YES 
user_id=65318

Aha, now I got it.

If once a thread is created and started and then stopped, 
the reference to the class is not cleared.  So, it seems to be 
ok if I do not invoke 'start' method of HTTPAdaptor.  I don't 
know why this happens, any ideas?



----------------------------------------------------------------------

Comment By: Trustin Lee (anoripi)
Date: 2004-07-06 10:07

Message:
Logged In: YES 
user_id=65318

I didn't look into the source code, but I could find 
WeakHashMap from my heap dump of MX4JMBeanServer:

mbeanServer= MX4JMBeanServer  (id=51)
	classLoaderRepository= 
DefaultClassLoaderRepository  (id=61)
	defaultDomain= ""
	delegate= MX4JMBeanServerDelegate  (id=66)
	delegateName= ObjectName  (id=72)
	domains= HashMap  (id=75)
	introspector= MBeanIntrospector  (id=80)
		bcelAvailable= false
		extendedMBeanInterfaces= false
		mbeanInfoCache= WeakHashMap  (id=88)
			entrySet= null
			keySet= null
			loadFactor= 0.75
			modCount= 11
			queue= ReferenceQueue  (id=91)
			size= 11
			table= WeakHashMap$Entry[16]  
(id=93)
			threshold= 16
			values= null
		mbeanInvokerCache= WeakHashMap  
(id=90)
			entrySet= null
			keySet= null
			loadFactor= 0.75
			modCount= 10
			queue= ReferenceQueue  
(id=112)
			size= 10
			table= WeakHashMap$Entry[16]  
(id=113)
			threshold= 16
			values= null
		mbeanInvokerClass= null
	invoker= MBeanServerInterceptorConfigurator  
(id=82)
	mbeanRepository= DefaultMBeanRepository  (id=85)


I can see two WeakHashMaps (whose keys are 
java.lang.Class type) are used by MX4J MBeanServer, and 
the size of the map increases over the time.  It is obvious 
that mx4j.tools.adaptor.http.HTTPAdaptor class is not GCed 
even if the classloader became unreachable by others. I 
explicitly called System.gc() many times, but the size of free 
memory (and the size of WeakHashMap, too) didn't decrease.

Strange thing is other classes from the other JARs are GCed 
when the MBean is unregistered.



----------------------------------------------------------------------

Comment By: Simone Bordet (biorn_steedom)
Date: 2004-07-05 22:29

Message:
Logged In: YES 
user_id=128193

The HTTPAdaptor can be run inside JMXRI, so there is no
coupling with MX4J core.

Can you be more precise when you say that "some WeakHashMap
is holding already unregistered MBeans' classes" ?
Where in the MX4J code ?

Thanks

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=450647&aid=985335&group_id=47745


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com