[ https://issues.apache.org/jira/browse/GROOVY-6704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14951009#comment-14951009 ]
Jochen Theodorou commented on GROOVY-6704: ------------------------------------------ doesn't compile? Ah man... I really dislike the way of reporting bugs at Oracle. that bug report was done by me. But of course not directly, instead I have to write someone, who then puts it in a JIRA. I myself have no chance of commented or writing directly on the issue. Which also means I cannot fix the typo, that got in there somehow. Ah well... Other is supposed to be Dummy. > Memory leak in ClassInfo when using MetaClasses > ----------------------------------------------- > > Key: GROOVY-6704 > URL: https://issues.apache.org/jira/browse/GROOVY-6704 > Project: Groovy > Issue Type: Bug > Affects Versions: 2.0.8, 2.1.9 > Reporter: Craig > Assignee: Jochen Theodorou > Priority: Critical > Fix For: 2.4.0-beta-2 > > Attachments: LeakTest.groovy > > > I'm trying to track down a memory leak in Grails and I'm pretty sure I've > discovered the root cause of the leak is in Groovy. For reference, here's the > thread on the grails-dev list on this topic: > http://grails.1312388.n4.nabble.com/Easily-reproducible-memory-leak-in-Grails-td4655816.html > I also raised this issue on the groovy-dev mailing list at > http://groovy.329449.n5.nabble.com/Memory-leak-in-ClassInfo-when-using-MetaClasses-td5719218.html > The problem is that when a class is loaded, then a metaclass is assigned, > then the class is no longer reachable, the metaclass remains in memory. When > this happens many times, lots of metaclasses are leaked, which becomes a > significant problem. I discovered this problem because this how Grails > implements GSPs - by loading the GSP as a groovy class, then when the GSP > changes, loading a new class. The old class is unreachable, except for some > internal Groovy structures... hence the memory leak. > Attached there is a junit test that reproduces this problem: > [^LeakTest.groovy] > Eventually, that results in an OutOfMemoryError. Using a tool like visualvm, > it is clear that the number of classes constantly rises, none are ever > unloaded, and the permgen keeps getting used. The heap also rises. In my > tests, it usually dies after about 5,000 iterations. > In my opinion, this shouldn't happen - this test case should run without > leaking memory. Groovy should allow the MetaClasses to be garbage collected > once the Class is no longer referenced by anything else. In other words, > Groovy should hold a weak reference to the MetaClass/ClassInfo/etc for the > Class based on the reachability of the Class. > By taking a heap dump in visualvm, I found that there are lots of instances > of org.codehaus.groovy.runtime.metaclass.MetaMethodIndex$Entry. > The problem areas (that are GC roots) seem to be: > org.codehaus.groovy.reflection.ClassInfo's static field modifiedExpandos > org.codehaus.groovy.reflection.ClassInfo's static field globalClassSet > The classes that area created by classLoader.parseClass also stick around, > which is why the permgen is leaking. > Can someone please help me determine how to fix this problem in Groovy? -- This message was sent by Atlassian JIRA (v6.3.4#6332)