[jira] [Commented] (GROOVY-6704) Memory leak in ClassInfo when using MetaClasses

2015-10-10 Thread Jochen Theodorou (JIRA) 

[ 
https://issues.apache.org/jira/browse/GROOVY-6704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14951758#comment-14951758
 ] 

Jochen Theodorou commented on GROOVY-6704:
--

you can make the class public, then it should work. But 20 minutes for 4 MB 
mx... wow, I remember that failing faster. Anyway, it fails. 

As for why LeakTest.groovy does not hit the problem.. my assumption is the 
following: The error happens only for class values added to higher class 
loaders, maybe it is even limited to application and or system classloader. So 
Integer would be an example for this. 

In LeakTest you do generate a big amount of clases, but they are children of a 
class loader hosting the registry. For classes like Integer there will be only 
one entry for the life cycle of that test. 

I extracted that failing test from a problem Cedric had with Gradle, that 
caused the Groovy runtime to load many many times. Took a while of our both 
time to condense it to a test case as simple as the one in the java bug tracker 
;) But I am happy I was able to exclude all of Groovy in that.

> 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: CVTest.java, LeakTest.groovy, MyClassValue.java
>
>
> 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)

[jira] [Commented] (GROOVY-6704) Memory leak in ClassInfo when using MetaClasses

2015-10-09 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/GROOVY-6704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 
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)

[jira] [Commented] (GROOVY-6704) Memory leak in ClassInfo when using MetaClasses

2015-10-09 Thread Craig (JIRA) 

[ 
https://issues.apache.org/jira/browse/GROOVY-6704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14950782#comment-14950782
 ] 

Craig commented on GROOVY-6704:
---

I did test it at the time, and I I just re-ran the test again.

JAVA_OPTS=-Xmx20m ./groovy ~/Downloads/LeakTest.groovy
fails after 373 iterations (which is to be expected as it's not using 
ClassValue so the original GROOVY-6704 occurs)

JAVA_OPTS=-Xmx20m ./groovy -Dgroovy.use.classvalue=true 
~/Downloads/LeakTest.groovy
ran seemingly indefinitely (I let it get to 3,000 iterations before I got bored)

Java version:
$ java -version
openjdk version "1.8.0_60"
OpenJDK Runtime Environment (build 1.8.0_60-b27)
OpenJDK 64-Bit Server VM (build 25.60-b23, mixed mode)

So the original LeakTest.groovy test still passes.

The test case at https://bugs.openjdk.java.net/browse/JDK-8136353 doesn't 
compile ("Other" is undefined) - do you know how to reproduce that issue?

Also, do we have a test case that reproduces GROOVY-7591? So far, I have no 
idea how to see the problem that resulted in the change being made for 
ClassValue to be disabled 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)

[jira] [Commented] (GROOVY-6704) Memory leak in ClassInfo when using MetaClasses

2015-10-09 Thread Jochen Theodorou (JIRA) 

[ 
https://issues.apache.org/jira/browse/GROOVY-6704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)