groovy

Memory Leak in Groovy ant task

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Duplicate
  • Affects Version/s: 1.6.1, 1.6.2, 1.6.3, 1.6.4
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Environment:
    Windows 32-Bit
  • Number of attachments :
    2

Description

When building larger projects using Groovy ant task there occurs a memory leak. When using Groovy 1.5.7 the leak is not there using all above that version including 1.6.4 the memory leak appears. It seems that classes do not get unloaded so the perm gen space accumulates. When many groovy and groovyc tasks are called in a ant build this becomes visible.

I am using ANT 1.7.1 libraries, but this problem does still occur when using ANT 1.7.0.

I was running JVM with -verbose:gc and found the following difference:

[Unloading class com.nsn.see.sce.entity.ArtifactExecutor]

is there in 1.5.7 but not in 1.6.4. So It does not clean up the classes that is inside the <groovy> task directly. It seems that the classes that are using by the ArtifactExecutor do get cleaned up.

May be the fact that I have nested the taskdef influences this problem?

<taskdef name="groovytools" classname="org.codehaus.groovy.ant.Groovy">
<classpath>
<path refid="groovytools.classpath"/>
</classpath>
</taskdef>

<groovytools>
import com.nsn.see.sce.entity.ArtifactExecutor
new ArtifactExecutor(ant).buildArtifacts()
</groovytools>

I attached the two extracts of the garbage collector.

  1. Text File
    groovy1.5.7.txt
    03/Aug/09 7:16 AM
    54 kB
    Richard Bock
  2. Text File
    groovy1.6.4.txt
    03/Aug/09 7:16 AM
    73 kB
    Richard Bock

Issue Links

is related to

Bug - A problem which impairs or prevents the functions of the product. GROOVY-3488 Groovy ant task memory leak (re-opened GROOVY-891)

  • Critical - Crashes, loss of data, severe memory leak.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Richard Bock added a comment -

analysing further I get the impression that the problem occurs through nesting of groovy tasks:

<target name="A">
<groovy>
ant.antcall("targetB")
</groovy>
</target>

<target name="B">
<groovy>
... some code
</groovy>
</target

In the build scripts there are many of these indirections from ant to groovy to ant and back to groovy. May be this gives problem when cleaning up the class loaders?

Show
Richard Bock added a comment - analysing further I get the impression that the problem occurs through nesting of groovy tasks: <target name="A"> <groovy> ant.antcall("targetB") </groovy> </target> <target name="B"> <groovy> ... some code </groovy> </target In the build scripts there are many of these indirections from ant to groovy to ant and back to groovy. May be this gives problem when cleaning up the class loaders?
Hide
Permalink
Richard Bock added a comment -

Groovy version 1.5.8 works correctly.

Show
Richard Bock added a comment - Groovy version 1.5.8 works correctly.
Hide
Permalink
Richard Bock added a comment -

I used jconsole and figured out what problem the JVM has. It runs out of memory pool "code cache". I do not know much about this memory pool. But as far as I could figure out it has something to do with the JIT compiler. That guy is optimizing the byte code. When I set the size up to 256 MByte it works fine. Finally the full build requires around 130MByte. With 1.5.8 I get around 20 MByte.

I do not know actually how to influence this memory pool nor what change from 1.5.8 to 1.6.4 is causing the problem.

When comparing the graphs on the code cache, with 1.6.4 the size is constantly increasing where with 1.5.8 the size also goes down some time. This indicates to me that there is some garbage collection taking place, where in the other case there is a leak.

Hope this gives you some clue on the problem.

Show
Richard Bock added a comment - I used jconsole and figured out what problem the JVM has. It runs out of memory pool "code cache". I do not know much about this memory pool. But as far as I could figure out it has something to do with the JIT compiler. That guy is optimizing the byte code. When I set the size up to 256 MByte it works fine. Finally the full build requires around 130MByte. With 1.5.8 I get around 20 MByte. I do not know actually how to influence this memory pool nor what change from 1.5.8 to 1.6.4 is causing the problem. When comparing the graphs on the code cache, with 1.6.4 the size is constantly increasing where with 1.5.8 the size also goes down some time. This indicates to me that there is some garbage collection taking place, where in the other case there is a leak. Hope this gives you some clue on the problem.
Hide
Permalink
Paul King added a comment -

linked to possibly related issue

Show
Paul King added a comment - linked to possibly related issue
Hide
Permalink
Paul King added a comment -

I am going to close this issue as a duplicate of GROOVY-3488. Please add further comments to that issue instead of this one.

Show
Paul King added a comment - I am going to close this issue as a duplicate of GROOVY-3488 . Please add further comments to that issue instead of this one.

People

  • Assignee:
    Paul King
    Reporter:
    Richard Bock
Vote (2)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: