[ https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15267011#comment-15267011 ]
ASF GitHub Bot commented on GROOVY-7683: ---------------------------------------- Github user blackdrag commented on a diff in the pull request: https://github.com/apache/groovy/pull/219#discussion_r61769520 --- Diff: src/main/org/codehaus/groovy/reflection/ClassInfo.java --- @@ -35,13 +36,13 @@ * * @author Alex.Tkachman */ -public class ClassInfo { +public class ClassInfo implements Finalizable { private final LazyCachedClassRef cachedClassRef; private final LazyClassLoaderRef artifactClassLoader; private final LockableObject lock = new LockableObject(); public final int hash = -1; - private final Class klazz; + private final WeakReference<Class<?>> klazz; --- End diff -- I think it would be sufficent to add to each method an according javadoc comment, as well as a class comment, that it is not safe to use without a Class associated with this ClassInfo. I would even consider a method to get the referenced Class, so people can check/ensure it will continue to exist. In that case we can probably avoid the checks and exceptions > Memory leak when using Groovy as JSR-223 scripting language. > ------------------------------------------------------------ > > Key: GROOVY-7683 > URL: https://issues.apache.org/jira/browse/GROOVY-7683 > Project: Groovy > Issue Type: Bug > Components: GroovyScriptEngine > Affects Versions: 2.4.5 > Environment: OS: tested on Mac OS X El Capitan and Windows 10. > JVM: tested on 1.8.0_60 and 1.8.0_65. > Reporter: Arkadiusz Gasinski > Labels: jsr-223 > Attachments: > 0001-GROOVY-7683-replace-hard-reference-from-ClassInfo-to.patch > > > We have a Java EE 7 web application in production that when handling single > HTTP request can load and execute up to several Groovy scripts using the > jsr-223 API. This application is deployed to GlassFish 4.1 server cluster > with 4 instances, each having 8 GB of RAM available (Xmx=8g). We have to > restart them every couple of days (3-4), because of leaking memory. After > analyzing a couple of heap dumps, our main suspect is Groovy with its > MetaMethodIndex$Entry class (the below table shows the top object from one of > the heap dumps). > ||Class Name||Objects||Shallow Heap||Retained Heap|| > |MetaMethodIndex$Entry| 3 360 001 | 188 160 056 | >= 305 408 024 > To confirm our suspicions, I created simple Maven project with a single test > case. The project is available on > [GitHub|https://github.com/jigga/groovy-jsr223-leak]. The test case executes > 10 different scripts (minimal differences) obtained from a single template > 20000 times in 64 worker threads (the main thread is put to sleep for 10 > seconds before starting worker threads, so that one can attach JVisualVM to > the test process). After all threads are done, System.gc() is called to > provoke full GC. Attaching to the process in which tests are run with > JVisualVM reveals that the memory is not reclaimed. > To run the test in your local environment, simply clone the > [GitHub|https://github.com/jigga/groovy-jsr223-leak] project and run: > {code} > mvn test > {code} > The same test can be run with the *-Dlanguage=javascript* system option, > which switches ScriptEngine from Groovy to Nashorn and uses slightly modified > script template (only syntactical differences). > {code} > mvn -Dlanguage=javascript test > {code} > Running the test case using built-in Nashorn engine reveals no problems - all > allocated memory is reclaimed after full GC. > I know that the test case is run in Java SE environment, but I guess that it > clearly reflects the issue. If it's not enough, I can create an arquillian > test case. > This may be a possible duplicate of > [GROOVY-7109|https://issues.apache.org/jira/browse/GROOVY-7109]. > Any workarounds for this issue would be greatly appreciated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)