commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clebert Suconic <csuco...@redhat.com>
Subject Re: Fwd: Circular Reference on WeakHashMap
Date Tue, 07 Aug 2007 02:34:52 GMT
 > Yes, but that reference can be garbage collected - so would have to
 > handle that as well. In this instance each AbstractConverter
 > implementation only ever returns the same value - so I think its
 > simpler to remove the class reference - for example in
 > IntegerConverter it would just have:

no... it won't...

As long as the ClassLoader is referenced somewhere, the WeakReference 
won't die. This is different on Reflection, as any class.getMethod() 
would return a brand new Method.


You probably have a WeakHashMap<ClassLoader, Cache>


When any application server releases the reference to classLoader, your 
WeakhashMap will automatically remove the element on the map, as long as 
you don't have Circular references to ClassLoader on the value:


There is a WIKI page I wrote about this, where I have written some 
information about it:


http://wiki.jboss.org/wiki/Wiki.jsp?page=ClassLeakage

Niall Pemberton wrote:
> On 8/7/07, Clebert Suconic <csuconic@redhat.com> wrote:
>>  > Yes it does (thru' AbstractConveter which it extends) - I can remove
>>  > that reference completely by just making the getDefaultType() method
>>  > abstract and having each implementation implement it.
>>  >
>>
>> Just an idea... You could just have the Abstract class holding a
>> WeakReference and then:
>>
>> WeakReference clazz;
>>
>> public void setClazz(Class clazz)
>> {
>>    this.clazz = new WeakReference(clazz);
>> }
>>
>> public Class getClazz()
>> {
>>     return (Class) clazz.get();
>> }
> 
> Yes, but that reference can be garbage collected - so would have to
> handle that as well. In this instance each AbstractConverter
> implementation only ever returns the same value - so I think its
> simpler to remove the class reference - for example in
> IntegerConverter it would just have:
> 
>     protected Class getDefaultType() {
>         return Integer.class;
>     }
> 
> Niall
> 
>> Niall Pemberton wrote:
>>> Woops, should have gone to dev@ list
>>>
>>> ---------- Forwarded message ----------
>>> From: Niall Pemberton <niall.pemberton@gmail.com>
>>> Date: Aug 7, 2007 2:36 AM
>>> Subject: Re: Circular Reference on WeakHashMap
>>> To: Clebert Suconic <csuconic@redhat.com>
>>>
>>>
>>> On 8/7/07, Clebert Suconic <csuconic@redhat.com> wrote:
>>>> The solution seems simpler than I thought though...
>>>>
>>>> After looking at the report again...
>>>> org.apache.commons.beanutils.converters.ClassConverter@22616909
>>>>
>>>> ClassConverter  probably has a reference to Class... I thought this was
>>>> a reflection object.
>>>>
>>>> It should be WeakReference<Class>.
>>> Yes it does (thru' AbstractConveter which it extends) - I can remove
>>> that reference completely by just making the getDefaultType() method
>>> abstract and having each implementation implement it.
>>>
>>>> And... inspect your code for any other reflection usages.
>>> OK when I get back I was going to have a play with JVMTIInterface - looks good.
>>>
>>> Niall
>>>
>>>> Niall Pemberton wrote:
>>>>> On 8/6/07, Clebert Suconic <csuconic@redhat.com> wrote:
>>>>>> I have been investigating WeakHashMaps on BeanUtils 1.8 as part of
a
>>>>>> investigation on this:
>>>>>>
>>>>>> http://jira.jboss.com/jira/browse/JBAS-2299
>>>>> Thanks for getting back to us so quickly.
>>>>>
>>>>>> (Which is not actually an issue with JBAS, but an issue when using
>>>>>> BeanUtils as part of the classPath).
>>>>>>
>>>>>> There is a circular reference on the WeakHashMap, The WeakHashMap
will
>>>>>> have the ClassLoader as the key, and it will have a reference back
to
>>>>>> the Key from one of the Reflection objects. This doesn't work! (Please..
>>>>>> no discussions about this point.. if you don't believe me, do some
>>>>>> testing with simple stuff before discussing this and come back to
me
>>>>>> only after that)
>>>>> OK I will.
>>>>>
>>>>>> org.jboss.web.tomcat.service.WebAppClassLoader@16334564
>>>>>> !--- sun.reflect.DelegatingClassLoader@27651708
>>>>>> !--- !--- class sun.reflect.GeneratedConstructorAccessor38
>>>>>> !--- !--- !--- [Ljava.lang.Object;@10800875
>>>>>> !--- !--- !--- !--- java.util.Vector@838806
>>>>>> !--- !--- !--- !--- !--- sun.reflect.DelegatingClassLoader@27651708
>>>>>> !--- !--- !--- !--- !--- !--- class
>>>>>> sun.reflect.GeneratedConstructorAccessor38
>>>>>> !--- !--- !--- !--- !--- !--- !--- class java.lang.Class
>>>>>> !--- !--- !--- !--- !--- !--- !--- !---
>>>>>> org.apache.commons.beanutils.converters.ClassConverter@22616909
>>>>>> !--- !--- !--- !--- !--- !--- !--- !--- !---
>>>>>> org.apache.commons.beanutils.converters.ArrayConverter@18888821
>>>>>> !--- !--- !--- !--- !--- !--- !--- !--- !--- !---
>>>>>> org.apache.commons.beanutils.converters.ConverterFacade@13619754
>>>>>> !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !---
>>>>>> java.util.HashMap$Entry@32434103
>>>>>> !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !---
>>>>>> [Ljava.util.HashMap$Entry;@28236766
>>>>>> !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !---
>>>>>> java.util.HashMap@14997495
>>>>>> !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !---
!---
>>>>>> org.apache.commons.beanutils.ConvertUtilsBean@2016953
>>>>>> !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !---
!---
>>>>>> !--- org.apache.commons.beanutils.BeanUtilsBean@30487951
>>>>>> !---!---!---!---!---!---!---!---!---!---!---!---!---!---!---!---
>>>>>> FieldReference private java.lang.Object
>>>>>> java.util.WeakHashMap$Entry.value=java.util.WeakHashMap$Entry@23775534
>>>>>> Detail
>>>>> I'm not familiar with JBoss's JVMTIInterface or its output - and it
>>>>> seems to be somewhat messed up in posting here - so I've (hopefully)
>>>>> cleaned it up and re-posted in a Jira ticket I've opened for this
>>>>> here:
>>>>>
>>>>> https://issues.apache.org/jira/browse/BEANUTILS-291
>>>>>
>>>>>> I don't know if I'm preaching to the choir, but just in case this
is new
>>>>>> information to someone... you should aways keep Reflection referenced
as
>>>>>> SoftReferences (if you really have to). Reflection is aways a new
object
>>>>>> so a WeakReference is too weak.
>>>>> Preach away - I have no great knowledge of this stuff.
>>>>>
>>>>>> On JBossSerialization I have solved this using an interesting way.
I
>>>>>> called it PersistentReference. I'm using SoftReferences, and keeping
the
>>>>>> information to recreate it case the SoftReference is cleared:
>>>>>>
>>>>>> http://fisheye.jboss.org/browse/JBoss/jboss-serialization/src/org/jboss/serial/references/PersistentReference.java?r=1.3
>>>>>>
>>>>>>
>>>>>> And also... you guys should write a testcase to validate if the Caching
>>>>>> is being cleared. (I don't know if you have one).
>>>>>>
>>>>>> http://anonsvn.jboss.org/repos/jbossserialization/trunk/tests/org/jboss/serial/memory/MemoryLeakTestCase.java
>>>>>>
>>>>>> You don't need to use the jboss-profiler API for this.. just create
a
>>>>>> WeakReference to a new ClassLoader, and validate if it was released
at
>>>>>> the end after some exercizing some code on this caching. You will
>>>>>> probably need to fill your memory almost to 100% on the test as
>>>>>> SoftReference are only gone when the memory is low.
>>>>> Unfortunately I'm away on holiday soon for 3 weeks (12th August to 2nd
>>>>> September) - so unless someone else picks this up - ii don't have time
>>>>> to look at this until after that. Do you mind if we move the
>>>>> discussion over to that Jira ticket I opened though?
>>>>>
>>>>> Niall
>>>>>
>>>>>> Clebert Suconic
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message