[
https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030676#comment-15030676
]
John Wagenleitner commented on GROOVY-7683:
-------------------------------------------
I tested the sample project with Groovy 2.3.11 and after the gc() call it
unloaded all but about 2k classes. The MetaMethodIndex$Entry instance count
dropped to 522. Tested with 2.4.0 and it behaves similar to 2.4.5 by not
unloading the script classes.
It looks like [commit
97d78e9e52deb52c8e66db501ef208f30384d014|https://github.com/apache/incubator-groovy/commit/97d78e9e52deb52c8e66db501ef208f30384d014]
may have introduced a hard reference to the class (klazz) in combination of
the ClassValue whereas I think it was a soft reference prior. In analyzing the
heap dump it looks like
{code}
java.lang.Thread
- <Java Local>, contextClassLoader sun.misc.Launcher$AppClassLoader
'- classes java.util.Vector
'- elementData java.lang.Object[1280]
'- [822] class org.codehaus.groovy.reflection.ClassInfo
'- globalClassValue
org.codehaus.groovy.reflection.GroovyClassValuePreJava7
'- map
org.codehaus.groovy.reflection.GroovyClassValuePreJava7$GroovyClassValuePreJava7Map
'- segments
org.codehaus.groovy.util.AbstractConcurrentMapBase$Segment[16]
'- [8]
org.codehaus.groovy.reflection.GroovyClassValuePreJava7$GroovyClassValuePreJava7Segment
'- table java.lang.Object[2048]
'- [1127]
org.codehaus.groovy.reflection.GroovyClassValuePreJava7$EntryWithValue
'- value org.codehaus.groovy.reflection.ClassInfo
'- klazz class Script15965
'- <classloader>
groovy.lang.GroovyClassLoader$InnerLoader
{code}
I'm not sure, but wanted to point it out since it seems to be a significant
change between 2.3.x and 2.4.x that may have an affect on this issue.
> 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
>
> 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)
