Re: [Springframework-developer] Re: CGLIB memory usage within class loader

[Rob H. <ro...@ca...>]

To add to what Chris is saying, the best way to keep memory usage is to 
implement equals() on your interceptors so that proxy classes can be 
reused as much as possible. I am going to look into a solution that will 
use weak references from the proxy class but strong references from 
proxy instances. This way once a proxy class is no longer used the 
advice chain and target can still be GCd. In the rare case when the 
advice chain is collected but the proxy class could still apply we can 
instruct CGLIB to create a new proxy class anyway - this will 
effectively remove this problem in all but the MOST extreme cases.

I will work on this as soon as I get back to work. I need access to a 
profiler to make this solution work properly and I don't have one at home.

Rob

Chris Nokleberg wrote:

>Rob Rudin wrote:
>  
>
>>Is there any chance that this will eventually be fixed in CGLIB?
>>We can get by with one context for all test methods, but as you
>>state, it would be nice for it not to be a problem when each
>>test method does need to create its own context.
>>    
>>
>
>CGLIB keeps an internal WeakReference-based per-ClassLoader cache of all
>generated classes, and tries to use it whenever possible. But if anything
>about the requested proxy changes, it does the safe thing and generates a
>new class. As Rob Harrop alluded to, for CGLIB to realize that one proxy is
>the same as another, among other things the Callback and CallbackFilter
>objects must implement equals/hashCode properly. Hibernate may have some
>issues in this regard, so you may want to file a bug with them.
>
>Chris
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
>Use IT products in your business? Tell us what you think of them. Give us
>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
>http://productguide.itmanagersjournal.com/guidepromo.tmpl
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>  
>