Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of niall.pemberton@gmail.com
 designates 209.85.134.189 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=opXxyhkyCtJ6jJpw8uAA6+9NjnxT8YZRsMCJtonaClNrLKqayjw7j6mRbtOOBUZ3hJvKgFhsYaki2hFZU/CXtuzTWlymnKalhE9IxW3VPePuee0A5CqWZlio2zxFJCUyEisIMz7w7QZhm3l8BxwdJP1a805anSzbr0U02T27h3U=
Message-ID: <55afdc850708061929q4103a30bwe9882af69a7d282c@mail.gmail.com>
Date: Tue, 7 Aug 2007 03:29:06 +0100
From: "Niall Pemberton" <niall.pemberton@gmail.com>
To: "Jakarta Commons Developers List" <dev@commons.apache.org>
Subject: Re: Fwd: Circular Reference on WeakHashMap
In-Reply-To: <46B7D5AD.4040103@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <46B79C8B.90303@redhat.com>
	 <55afdc850708061751v35bd96b5xb2868907f18fcd09@mail.gmail.com>
	 <46B7CA35.3080402@redhat.com>
	 <55afdc850708061836s5ccc273ex138264054a5fa292@mail.gmail.com>
	 <55afdc850708061837u61eb87e1v20a4d9d84d2f7be@mail.gmail.com>
	 <46B7D5AD.4040103@redhat.com>

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