On 05/06/2013, at 3:57 AM, Luke Daley <luke.da...@gradleware.com> wrote:
> Hi, > > I just tracked down a memory leak in the Artifactory plugin. I've raised with > them to fix this, but this is a symptom of a more general leak we have in > place… I think. > > Groovy keeps a global registry of metaclass of all loaded classes that get > touched by Groovy. We load Groovy in a persistent classloader across builds. > This means that build level user classes (e.g. non core plugins) end up > getting loaded into Groovy's metaclass registry each time there is a build. > This means we are always leaking permgen, and that we are very susceptible to > bad leaks if user code keeps a static state reference to something, as was > the case with the artifactory plugin. They ended up holding on to a reference > of the root project statically (through Groovy meta programming) which means > a lot was leaked. > > We can't really change the classloader structure to unload the whole meta > class registry between builds as that would defeat the main purpose of the > daemon: to load Groovy once. The purpose of the daemon is to keep the things that a build needs warmed-up. This includes groovy, but it also includes the user classes used by the build (and other state, too). So, we only want to discard the classes and associated meta-data that we think are unlikely to be needed any more - classes from class loaders that we discard because their classpath has changed or class loaders that we discard because we haven't run the associated build for a while. There are a couple of other things we can do: The daemon should watch memory usage and restart when we're going to run out, with the appropriate warnings when it has to do this too often. We should also tear apart a model once we're finished with it, so that leaks where a model object is retained will consume less stuff. We should also discard event listener and actions once we're finished with them. We should also push on with the decoupled configuration model, as this will chop the single giant model graph into much smaller pieces. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: http://www.gradlesummit.com
