Spring Tool Suite
  1. Spring Tool Suite
  2. STS-3079

Major memory Leak on clean build of grails project

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 3.1.0.RELEASE
    • Fix Version/s: 3.3.0.M1
    • Component/s: GRAILS
    • Labels:
      None
    • Environment:

      OSX 10.7.4
      GGTS 3.10
      grails 2.1

      Description

      In workbench preference enable General->Show Heap Status.

      In Workbench menu -> project -> clean -> start a build immediately.
      After the build, the heap memory increases by over 200mb.
      Repeating this clean step, multiple times will hangs the IDE.

      Even with small projects, the amount of heap memory use, always increase significantly after each build.

        Issue Links

          Activity

          Hide
          Andrew Eisenberg (c) added a comment -

          Thanks for the second project. I made a few small changes that seem to have a big affect on memory usage. We are now using WeakHashMaps to store ClassNodes in various places. Also, we lazily initialize some parts of AST nodes.

          With these changes, I am able to consistently do full compiles of your memTest500.zip project (even though there is a little bit of thrashing sometimes on a 1Gb heap). Without these changes, I cannot compile the project at all.

          Please install the latest dev build and let me know if this provides any benefits. See here for the update sites to use for dev builds:

          http://groovy.codehaus.org/Eclipse+Plugin#EclipsePlugin-DevelopmentBuilds

          Show
          Andrew Eisenberg (c) added a comment - Thanks for the second project. I made a few small changes that seem to have a big affect on memory usage. We are now using WeakHashMaps to store ClassNodes in various places. Also, we lazily initialize some parts of AST nodes. With these changes, I am able to consistently do full compiles of your memTest500.zip project (even though there is a little bit of thrashing sometimes on a 1Gb heap). Without these changes, I cannot compile the project at all. Please install the latest dev build and let me know if this provides any benefits. See here for the update sites to use for dev builds: http://groovy.codehaus.org/Eclipse+Plugin#EclipsePlugin-DevelopmentBuilds
          Hide
          Henry Lai added a comment -

          Thanks, it is better than before. For my actual project, I can now run 6 builds, whereas before it hangs on the second build.

          On the seventh build, it appears to hang, but after 5 minutes, error dialog popup with the following message:

          Activity Monitor Job
          Building workspace

          An internal error occurred during: "Building workspace".
          Java heap space

          Show
          Henry Lai added a comment - Thanks, it is better than before. For my actual project, I can now run 6 builds, whereas before it hangs on the second build. On the seventh build, it appears to hang, but after 5 minutes, error dialog popup with the following message: Activity Monitor Job Building workspace An internal error occurred during: "Building workspace". Java heap space
          Hide
          Andrew Eisenberg (c) added a comment -

          Thanks for the feedback. I'll take more of a look and see what else I can squeeze out. From what I'm seeing, there is no leak. Rather, weak references are being kept around too long and not GC-ed until it's too late.

          Show
          Andrew Eisenberg (c) added a comment - Thanks for the feedback. I'll take more of a look and see what else I can squeeze out. From what I'm seeing, there is no leak. Rather, weak references are being kept around too long and not GC-ed until it's too late.
          Hide
          Andrew Eisenberg (c) added a comment -

          We have just committed a fix that avoids a permgen leak. For Grails 2.1.x, when performing a build, an ivy classloader is pushed into a threadlocal and this classloader was never removed after the operation was complete. This means that the classloaders stuck around for as long as the thread was alive. This also means that if builds were happening on multiple threads (which is common), you would get a lot of permgen wasted due to each builder thread keeping its own ivy context around.

          I tested your project on this change and things seem to be behaving a bit better for me. If you get a chance, please upgrade to the latest groovy-ecipse dev snapshot (update site is above).

          Show
          Andrew Eisenberg (c) added a comment - We have just committed a fix that avoids a permgen leak. For Grails 2.1.x, when performing a build, an ivy classloader is pushed into a threadlocal and this classloader was never removed after the operation was complete. This means that the classloaders stuck around for as long as the thread was alive. This also means that if builds were happening on multiple threads (which is common), you would get a lot of permgen wasted due to each builder thread keeping its own ivy context around. I tested your project on this change and things seem to be behaving a bit better for me. If you get a chance, please upgrade to the latest groovy-ecipse dev snapshot (update site is above).
          Hide
          Andrew Eisenberg (c) added a comment -

          No response for a while now. Things are behaving significantly better for my own workspaces now. If you continue to have memory issues, let me know and I will look some more.

          Show
          Andrew Eisenberg (c) added a comment - No response for a while now. Things are behaving significantly better for my own workspaces now. If you continue to have memory issues, let me know and I will look some more.

            People

            • Assignee:
              Andrew Eisenberg (c)
              Reporter:
              Henry Lai
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                First Response Date: