[
https://issues.apache.org/jira/browse/GROOVY-6704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14950653#comment-14950653
]
ASF GitHub Bot commented on GROOVY-6704:
----------------------------------------
GitHub user candrews opened a pull request:
https://github.com/apache/incubator-groovy/pull/137
GROOVY-6704 Use ClassValue by default on IBM Java
IBM Java doesn't have the ClassValue garbage collection issue that OpenJDK
has (https://bugs.openjdk.java.net/browse/JDK-8136353) so when running on that
JVM, enable ClassValue by default.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/candrews/incubator-groovy patch-1
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/incubator-groovy/pull/137.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #137
----
commit d63f5dc62cf26a9abe16c15d046389cc273a7f11
Author: Craig Andrews <candr...@integralblue.com>
Date: 2015-10-09T16:30:10Z
GROOVY-6704 Use ClassValue by default on IBM Java
IBM Java doesn't have the ClassValue garbage collection issue that OpenJDK
has (https://bugs.openjdk.java.net/browse/JDK-8136353) so when running on that
JVM, enable ClassValue by default.
----
> 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)
