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. groovy1.5.7.txt
        54 kB
        Richard Bock
      2. groovy1.6.4.txt
        73 kB
        Richard Bock

        Issue Links

          Activity

          Hide
          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
          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
          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
          Paul King added a comment -

          linked to possibly related issue

          Show
          Paul King added a comment - linked to possibly related issue
          Hide
          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
            • Votes:
              2 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: