commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niall Pemberton" <niall.pember...@gmail.com>
Subject Re: Fwd: Circular Reference on WeakHashMap
Date Tue, 07 Aug 2007 02:43:36 GMT
On 8/7/07, Clebert Suconic <csuconic@redhat.com> wrote:
>  > 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.

Ahhh OK.

> 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

Great, thanks I'll take a look.

Niall

> 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
>
>

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


Mime
View raw message