-
30. Re: JBAS-3016 - Memory Leaks on redeployments
"clebert.suconic@jboss.com" wrote:
every class loaded in more than one class loader. When you redeploy packages and they are not GCed you will see duplications
See WeakClassCache code.public abstract class WeakClassCache { ...... public Object get(Class clazz) { ....... Map classLoaderCache = getClassLoaderCache(clazz.getClassLoader()); ....... } ........... protected Map getClassLoaderCache(ClassLoader cl) { synchronized (cache) { Map result = (Map) cache.get(cl); if (result == null) { result = CollectionsFactory.createConcurrentReaderMap(); cache.put(cl, result); } return result; } } }
I think may not every class loaded in more than one class loader, When you redeploy packages.
They are not GCed which is class's MetaData.
They are trying to reduce class's references resolving time.
is it right ?
ps: Sorry post there,Please excuse me if is naughtily -
31. Re: JBAS-3016 - Memory Leaks on redeployments
bkeh12, We didn't find any reference to WeakClassCache on these tests. So, this class is out of the scope of this thread. Probably you didn't read this whole thread. (it's kind of long but you will need to catch up the conversation to understand what's going on).
The context of having a class loaded by two different classLoaders was about redeployments.
If you think that WeakClassCache is suspisious you could try reproducing a memory leak within JBoss Code. I personally don't think so, as undeployers are probably taking care of that. -
32. Re: JBAS-3016 - Memory Leaks on redeployments
Kabir, I have good news.
I found what was going wrong with ScopeTestCase and the memory leak tests.
I ripped ScopeTestCase apart until I found the root cause of this testcase.
I started removing tests, and even after every test was removed I was still seeing memory leaks.
I kept seeing this until the only thing left on ScopeTestCase was:public class ScopeTestCase extends TestCase { private void checkSimilarities( boolean[] same) { } }
So, don't ask me why, this is just a fact, that was really hard to be reproduced. So, basically when using this framework we can't use any primitive array on any method parameters. It would be better to discover why so when we have more people using it we would have a better understanding on what happened. -
33. Re: JBAS-3016 - Memory Leaks on redeployments
Well... another very good news.
ScopeTestCase was failing because LogManager.getInstance() (called inside MarshalledObject as you pointed me out) is creating a Thread and attaching currentContextClassLoader on that Thread.
So, everything I had to do was call LogManager.getInstance() before setting ContextClassLoader to the ClassLoader created.
So, at this point now we have 100% on the memory leak tests on that branch.
Please, when you join the branches, don't forget to also update MemoryLeakTestCase with my fixes. -
34. Re: JBAS-3016 - Memory Leaks on redeployments
BTW: Shouldn't we open a bug against java.util.logging.LogManager?
Why Sun is using ContextClassLoader here when it's not used for nothing?
They should just be using just SystemClassLoader.
I did a quick search over BugParade and didn't see anything. Maybe I didn't do the proper search. -
35. Re: JBAS-3016 - Memory Leaks on redeployments
"clebert.suconic@jboss.com" wrote:
bkeh12, We didn't find any reference to WeakClassCache on these tests. So, this class is out of the scope of this thread. Probably you didn't read this whole thread. (it's kind of long but you will need to catch up the conversation to understand what's going on).
The context of having a class loaded by two different classLoaders was about redeployments.
If you think that WeakClassCache is suspisious you could try reproducing a memory leak within JBoss Code. I personally don't think so, as undeployers are probably taking care of that."adrian@jboss.org" wrote:
That is what ClassInfo does
WeakClassCache is used in MC's reflect stuff. -
36. Re: JBAS-3016 - Memory Leaks on redeployments
WeakClassCache is used in MC's reflect stuff.
I guess the next place I'm going to create testcases for redeployments is MC.
even there is not MemoryLeaks this will at least prevent them to occur.
Adrian, sounds good? -
37. Re: JBAS-3016 - Memory Leaks on redeployments
"clebert.suconic@jboss.com" wrote:
WeakClassCache is used in MC's reflect stuff.
I guess the next place I'm going to create testcases for redeployments is MC.
I had tried to test but MemoryLeaks is gone.
I guess
They are not GCed which is class's MetaData.
They are trying to reduce class's references resolving time.
You can use org.jboss.test.classinfo.test.IntrospectionClassInfoTestCase for test. -
38. Re: JBAS-3016 - Memory Leaks on redeployments
Hi clebert,This is MC MemoryLeaks test.
+++oldloader =sun.misc.Launcher$AppClassLoader@16930e2 +++newloader =java.net.FactoryURLClassLoader@23e5d1 +++newloader1 =java.net.FactoryURLClassLoader@c4fe76 ==>Introspection-loadclass=org.jboss.test.classinfo.support.SimpleBean [classloader]=java.net.FactoryURLClassLoader@23e5d1 ==>classLoaderCache-classloader=java.net.FactoryURLClassLoader@23e5d1 ==>classLoaderCache-classloader-class=org.jboss.test.classinfo.support.SimpleBean [classloader]=java.net.FactoryURLClassLoader@23e5d1 [weak]=java.lang.ref.WeakReference@1dec1dd ==>classLoaderCache-classloader=null ==>classLoaderCache-classloader-class=java.lang.Object [classloader]=null [weak]=java.lang.ref.WeakReference@aa233f ==>classLoaderCache-classloader-class=java.io.Serializable [classloader]=null [weak]=java.lang.ref.WeakReference@1f01a29 ==>classLoaderCache-classloader-class=org.jboss.test.classinfo.support.SimpleInterface [classloader]=java.net.FactoryURLClassLoader@23e5d1 [weak]=java.lang.ref.WeakReference@458f41 ==>Introspection-loadclass=org.jboss.test.classinfo.support.SimpleBean [classloader]=java.net.FactoryURLClassLoader@c4fe76 ==>classLoaderCache-classloader=java.net.FactoryURLClassLoader@c4fe76 ==>classLoaderCache-classloader-class=org.jboss.test.classinfo.support.SimpleBean [classloader]=java.net.FactoryURLClassLoader@c4fe76 [weak]=java.lang.ref.WeakReference@4ac216 ==>classLoaderCache-classloader-class=org.jboss.test.classinfo.support.SimpleInterface [classloader]=java.net.FactoryURLClassLoader@c4fe76 [weak]=java.lang.ref.WeakReference@c5e9c +++references clear and forceGC Class org.jboss.reflect.plugins.MethodInfoImpl Field[0] serialVersionUID...error Field is final Field[1] name...error null Field[2] declaringClass...error null Field[3] parameterTypes...error null Field[4] parameters...error null Field[5] exceptionTypes...error null Field[6] modifiers...error null Field[7] returnType...error null Field[8] hash...error null Field[9] serialVersionUID...error Field is final Field[10] annotationsArray...error null Field[11] annotationMap...error null Field[12] log...error null Field[13] toString...error null Field[14] hashCode...error null Class org.jboss.reflect.spi.MethodInfo Field[0] NO_PARAMS_TYPES...error Field is final Field[1] NO_PARAMS...error Field is final Field[2] NO_EXCEPTIONS...error Field is final Class [Lorg.jboss.reflect.spi.MethodInfo; objects[0] [Lorg.jboss.reflect.spi.MethodInfo;@a83a13 Class org.jboss.reflect.spi.TypeInfoFactory objects[0] org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactory@7cd37a objects[1] org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactoryImpl@1202d69 objects[2] org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactory@1855562 Class org.jboss.reflect.plugins.introspection.ReflectFieldInfoImpl Field[0] serialVersionUID...error Field is final Field[1] field...error null Field[2] serialVersionUID...error Field is final Field[3] name...error null Field[4] type...error null Field[5] modifiers...error null Field[6] declaringClass...error null Field[7] hash...error null Field[8] serialVersionUID...error Field is final Field[9] annotationsArray...error null Field[10] annotationMap...error null Field[11] log...error null Field[12] toString...error null Field[13] hashCode...error null ... there are more... I had to cut the report here, or it would be too big otherwise
adrian, is MC MemoryLeaks ? -
39. Re: JBAS-3016 - Memory Leaks on redeployments
I created another forum post into microcontainer to continue this discussion there:
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3937413#3937413 -
40. Re: JBAS-3016 - Memory Leaks on redeployments
Kabir asked me to take a look on why SimpleBeanUnitTestCase was still causing duplciates:
jboss-head-eclipse\testsuite>ant -Dtest=org.jboss.test.aop.test.SimpleBeanUnitTestCase one-test
After a long analysis, I discovered that AspectManager is holding references on registeredCLs. Probably when an application uses two classLoaders and gets undeployed only one classLoader is unregistered through unregisterClassLoader which is called on undeploments.
Making registeredCLs solved the duplications:public class AspectManager implements Translator { private static ThreadLocal REENTRY = new ThreadLocal() { protected Object initialValue() { return Boolean.FALSE; } }; // Attributes --------------------------------------------------- protected WeakHashMap registeredCLs = new WeakHashMap();
I commited the code, but I need Kabir to validate colateral effects on registeredCLs as a weakReference. (I would think is okay, but he is the lead, right?)
(Man, looking for memory leaks on redeployments is like a dirty job. We should call Discovery Channel who has a TV series about that here is US :-) )
http://dsc.discovery.com/fansites/dirtyjobs/splash.html -
41. Re: JBAS-3016 - Memory Leaks on redeployments
I've created an AOP 1.5.0 snapshot in the 4.0 branch, which contains the fixes I added
-
42. Re: JBAS-3016 - Memory Leaks on redeployments
We will probably need another issue stating the update of AOP to 1.5.0 on JBoss 4.0.4.
Also, the snapshot is good to a release, or this is just a temporary solution until you get the tests passed? -
43. Re: JBAS-3016 - Memory Leaks on redeployments
It is temporary until I get the tests passed, I will release 1.5.0 proper then (before the 4.0.4 release)