13 Oct 2004 09:58
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/
>
> 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...
>
> --
>
RSS Feed