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 only way I can see out of this is to forcibly track what classes get into the meta class registry during a build that are not reachable from the class loader that loaded groovy and to remove them from the registry once done. The Groovy metaclass registry appears to provide the necessary hooks for us to do this. Should I raise a ticket? Am I missing something? -- Luke Daley Principal Engineer, Gradleware http://gradleware.com Join me at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: http://www.gradlesummit.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
