Hi, Here's most elaborate response from the list. They recommend us to test with the 1.6 beta version as well (has some fixes around the topic). I'm trying with it and putting it in the server lib folder. In addition to Groovy do you want any other libs moved there?

And thank you very much for the work on the issue.

Regards,

---------- Forwarded message ---------- From: Jochen Theodorou <blac...@gmx.org> Date: Wed, Oct 15, 2008 at 7:44 PM Subject: Re: [groovy-user] Memory leaks in Groovy To: us...@groovy.codehaus.org

Jose Noheda schrieb:

Hi,

ok, let us try to get a little forward on this one... the thread local storage (TLS) is a weak hashmap. That means that the keys are weak referenced, but the values are soft referenced and they have hard links to the classes, which are the weak referenced keys. So in the end the keys are to be seen as if they are soft referenced.

So as long as there is memory the TLS will increase... it was mentioned there, that they saw the application taking much memory and then freeing it in the permgen... this sounds very much like what you get for soft reference.

If I for example execute this program:

def script = ''' def foo(){1} 1+foo() ''' def registry = GroovySystem.metaClassRegistry 100000.times { if (it%100==0) { println soft meta classes: ${registry.weakMetaClasses.size()}" } def shell = new GroovyShell() assert shell.evaluate(script) == 2 }

then I get 10-11 soft meta classes, but each iteration creates a new groovy class. So they must be collected. If I use for example this script:

def script = ''' def foo(){1} 1+foo() ''' def registry = GroovySystem.metaClassRegistry def loader = new GroovyClassLoader(this.class.classLoader) 100000.times { if (it%100==0) { println "weak meta classes: ${registry.weakMetaClasses.size()}" } assert loader.parseClass(script).newInstance().run() == 2 }

then the classes remain referenced, because the GroovyClassLoader is holding them and each iteration shows a higher count of meta classes, because the classes are not collected. In fact you still get several thousand iterations this way, because the meta class might be collected even if the class is not. The meta class has its own soft reference and can be collected by itself. So first thing is you run in a permgen problem, because the classes are still here.

inner classes are mentioned... the only case Groovy creates them is when closures are used... so let us extend the script a little:

def script = ''' def foo(){1} def c = {foo()} 1+c() '''

now the count rises much faster, but there is still no problem. The script you gave seems not to produce any inner classes too.

So I still think that there is somewhere a classloader that is hard linked. since you use no class loaders from GroovyI doubt Groovy has really a problem here...just in case... is it possible for you to update to 1.5.7? I don't think we fixed any important bug that may affect this, but who knows.

bye blackdrag