Uploaded image for project: 'Spring Tool Suite'
  1. Spring Tool Suite
  2. STS-3079

Major memory Leak on clean build of grails project

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: 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
          aeisenberg Andrew Eisenberg 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
          aeisenberg Andrew Eisenberg 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
          hlai888 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
          hlai888 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
          aeisenberg Andrew Eisenberg 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
          aeisenberg Andrew Eisenberg 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
          aeisenberg Andrew Eisenberg 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
          aeisenberg Andrew Eisenberg 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
          aeisenberg Andrew Eisenberg 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
          aeisenberg Andrew Eisenberg 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:
              aeisenberg Andrew Eisenberg
              Reporter:
              hlai888 Henry Lai
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: