You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Niall Pemberton <ni...@blueyonder.co.uk> on 2005/10/07 07:17:09 UTC

[BeanUtils] Memory Issues

There are a couple of issues regarding memory leaks in BeanUtils for
"caches" that are keyed by java.lang.Class. I have limited
memory/ClassLoader knowledge and I was hoping someone would comment on a
suggestion I posted to resolve this.

Rather than using the Class as the key for these caches how about generating
a key using the Class's name and the ClassLoader's hashcode. Is this a
good/bad idea?

  String classKey = beanClass.getName() +
                                  beanClass.getClassLoader().hashCode();

I posted a patch for WrapDynaClass to the bug:

      http://issues.apache.org/bugzilla/show_bug.cgi?id=35263

There is also the same issue for PropertyUtilsBean

Niall



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


Re: [BeanUtils] Memory Issues

Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
Thanks for the suggestion James, I'll update my proposed patch with this:

       http://issues.apache.org/bugzilla/show_bug.cgi?id=35263

Niall

----- Original Message ----- 
From: "James Carman" <ja...@carmanconsulting.com>
Sent: Friday, October 07, 2005 12:37 PM


> I might suggest using System.identityHashCode() rather than the hashCode()
> of the classloader itself just in case a ClassLoader implementation
doesn't
> "play nice" with respect to its implementation of hashCode().  We did
> something similar in HiveMind.
>
> -----Original Message-----
> From: Niall Pemberton [mailto:niall.pemberton@blueyonder.co.uk]
> Sent: Friday, October 07, 2005 1:17 AM
> To: Commons Developers Jakarta
> Subject: [BeanUtils] Memory Issues
>
> There are a couple of issues regarding memory leaks in BeanUtils for
> "caches" that are keyed by java.lang.Class. I have limited
> memory/ClassLoader knowledge and I was hoping someone would comment on a
> suggestion I posted to resolve this.
>
> Rather than using the Class as the key for these caches how about
generating
> a key using the Class's name and the ClassLoader's hashcode. Is this a
> good/bad idea?
>
>   String classKey = beanClass.getName() +
>                                   beanClass.getClassLoader().hashCode();
>
> I posted a patch for WrapDynaClass to the bug:
>
>       http://issues.apache.org/bugzilla/show_bug.cgi?id=35263
>
> There is also the same issue for PropertyUtilsBean
>
> Niall



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


RE: [BeanUtils] Memory Issues

Posted by James Carman <ja...@carmanconsulting.com>.
I might suggest using System.identityHashCode() rather than the hashCode()
of the classloader itself just in case a ClassLoader implementation doesn't
"play nice" with respect to its implementation of hashCode().  We did
something similar in HiveMind.

-----Original Message-----
From: Niall Pemberton [mailto:niall.pemberton@blueyonder.co.uk] 
Sent: Friday, October 07, 2005 1:17 AM
To: Commons Developers Jakarta
Subject: [BeanUtils] Memory Issues

There are a couple of issues regarding memory leaks in BeanUtils for
"caches" that are keyed by java.lang.Class. I have limited
memory/ClassLoader knowledge and I was hoping someone would comment on a
suggestion I posted to resolve this.

Rather than using the Class as the key for these caches how about generating
a key using the Class's name and the ClassLoader's hashcode. Is this a
good/bad idea?

  String classKey = beanClass.getName() +
                                  beanClass.getClassLoader().hashCode();

I posted a patch for WrapDynaClass to the bug:

      http://issues.apache.org/bugzilla/show_bug.cgi?id=35263

There is also the same issue for PropertyUtilsBean

Niall



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



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