On 05/06/2013, at 2:37, Adam Murdoch <adam.murd...@gradleware.com> wrote:
> > 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. My read of things was that we don't cache any user code at the moment. The growing meta class registry seems to indicate that we are dumping user classes between builds. > 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 >
