Groovy ant task memory leak (re-opened GROOVY-891)

Please see test case attached to http://jira.codehaus.org/browse/GROOVY-891.

This issue still exists under Ant 1.7.1 + Groovy 1.6. The memory leak is severe enough that it causes the AribaWeb (http://aribaweb.org) build to sometimes run out of memory even with Ant configured with a very large heap. (e.g. ANT_OPTS=-Xmx400m -XX:MaxPermSize=300m).

I had a similar effect when running several Canoo webtests in one Ant script (and therefor one JVM). The webtest starter ant script uses the Groovy ant task to run its scripts written in Groovy.
The OOME affects the heap, not the permspace.

A possible fix that solved the issue for me was to release some resources of the GroovyShell that is used in the Groovy ant task.

In the method execGroovy(), the last two lines construct a new GroovyShell and uses it. Afterwards, the instance is omitted as it's only locally scoped.
Explicitly freeing up the caches of the shell fixed the OOME for me:

final GroovyShell groovy = new GroovyShell(classLoader, new Binding(), configuration);
try {
    parseAndRunScript(groovy, txt, mavenPom, scriptName, null, new AntBuilder(this));
} finally {
    groovy.resetLoadedClasses();
    groovy.getClassLoader().clearCache();
}

I hope this helps a bit

Well, the line separators didn't work out:

final GroovyShell groovy = new GroovyShell(classLoader, new Binding(), configuration);
try {
    parseAndRunScript(groovy, txt, mavenPom, scriptName, null, new AntBuilder(this));
} finally {
    groovy.resetLoadedClasses();
    groovy.getClassLoader().clearCache();
}

So be it, then. Sorry

Daniel, you should try using {code} tags. Click the little help icon while editing/entering.

Problem is reproducible with Ant 1.8 and Groovy trunk - though it does take until step 38 out of 40 before it gets the OOM error!
Using groovy.resetLoadedClasses() in the finally block did not seem to fix the problem for the Ant build test case. Perhaps it is worth doing anyway if it fixes similar issues for WebTest. I can't see any downside - though if we can find a fix for both that would be better.

Davide, that your example fails with a permgen problem is actaully what I expect. Each run of GroovyShell will add a new class and the class is not removed somewhere, that is by design. Instead you are supposed to use a new GroovyShell for each call or at least from time to time. Then the classes could be collected.

getting the loader fom the shell and call resetLoadedClasses on it is a workaround in case you don't want to create a new instance

The resetLoadedClasses() and clearCache() suggestion have been added to 1_7_X, 1_8_X and trunk. I don't think they fix all cases but certainly seem to help.

Reading the comments I guess this issue should be closed?

Closing this as the discussion is around old versions of Groovy and dependencies. There are other issues addressing memory leakage, e.g. GROOVY-6068, but please reopen a new issue with specific details if you are still having problems with recent versions.