[bkeh12]

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

[clebert.suconic]

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.

[clebert.suconic]

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.

[clebert.suconic]

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.

[clebert.suconic]

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.

[bkeh12]

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.

That is what ClassInfo does

WeakClassCache is used in MC's reflect stuff.

[clebert.suconic]

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?

[bkeh12]

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.

[bkeh12]

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 ?

[clebert.suconic]

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

[clebert.suconic]

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

[kabirkhan]

I've created an AOP 1.5.0 snapshot in the 4.0 branch, which contains the fixes I added

[clebert.suconic]

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?

[kabirkhan]

It is temporary until I get the tests passed, I will release 1.5.0 proper then (before the 4.0.4 release)