Hi, I believe that there is already a ticket open for this issue [1]. The @Groovy mixin annotation has the same metaclass registry problem.
It's been biting me hard for the past few months in the grails world. I have tried going down the route of tracking the added metaclasses, and removing them as necessary, and it proved to be difficult and time consuming. However, I was trying to tackle the issue a different way, so this info might not apply. [1] http://jira.codehaus.org/browse/GROOVY-4858 On Tue, Jun 4, 2013 at 1:57 PM, 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 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 > > >
