jastrachan | 13 Oct 09:58 2004
Picon

Re: [groovy-dev] InvokerHelper holds on to all Groovy Classes

I like the first option - associating the MetaClass instances with the 
class loader - though it might be a bit fiddley to achieve.
The weak reference on a per MetaClass instance could well be an easy 
fix to implement.

On 13 Oct 2004, at 08:41, Jeremy Rayner wrote:
> In reference to Brian Oliver's issue (
> http://jira.codehaus.org/browse/GROOVY-649 ), I've been having a quick
> peek around the consequences of evaluating groovy expressions.
>
> * I've done some empirical tests, varying the test case given,
> observing timings and memory usage.
> * and using the YourKit Java Profiler ( http://www.yourkit.com ), I've
> had a look at what is hogging the most time and memory.
>
> jez's notes: ( 
> http://biscuit.javanicus.com:5909/GroovyMemoryUsageDuringEvaluations
> )
>
>
> From this my observations, the thing that strikes me most is the
> static property 'singleton' of type Invoker on InvokerHelper.
>
> My understanding of the issue is...
>
> * The Invoker instance holds a reference to a MetaClassRegistry, which
> in turn holds a synchronized HashMap of MetaClass instances called
> 'metaClasses'.
>
> * 'metaClasses' is an expensive object in terms of object size, and as
> there is one per JVM, it will end up with a reference to all MetaClass
> instances.
>
> * It is my understanding that as the 'singleton' is statically
> initialised with a new instance, then the expensive 'metaClasses'
> object will indirectly be held by the main ClassLoader holding the
> InvokerHelper Class reference.
>
> Solutions:
> * refactor the 'singleton' instance into GroovyClassLoader, so that
> the 'metaClasses' object gets GC'd when the GCL does.
> * Make 'singleton' on InvokerHelper into a WeakReference
> * Make 'metaClasses' into a WeakReference
> * Refactor every method that uses 'singleton' in InvokerHelper, so
> that you pass an Invoker instance as a method parameter
> * Other suggestions welcomed :-)
>
> My feeling is towards the first at the moment, as it would keep the
> heavy object references in the same lifecycle as the
> GroovyClassLoader.
>
> Also I have a general distrust of static properties and static
> initialisers, and would like to move this toward a picocontainer style
> dependancy injection if possible
>
> Thoughts, comments, flames...
>
> -- 
> http://javanicus.com/blog2
>
>

James
-------
http://radio.weblogs.com/0112098/


Gmane