[
https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15058025#comment-15058025
]
Jochen Kemnade edited comment on GROOVY-7683 at 12/16/15 2:29 PM:
------------------------------------------------------------------
I'm also experiencing those leaks.
{noformat}
this - value: org.codehaus.groovy.reflection.ClassInfo #392
<- value - class:
org.codehaus.groovy.reflection.GroovyClassValuePreJava7$EntryWithValue, value:
org.codehaus.groovy.reflection.ClassInfo #392
<- [65] - class: java.lang.Object[], value:
org.codehaus.groovy.reflection.GroovyClassValuePreJava7$EntryWithValue #317
<- table - class:
org.codehaus.groovy.reflection.GroovyClassValuePreJava7$GroovyClassValuePreJava7Segment,
value: java.lang.Object[] #424042
<- [11] - class:
org.codehaus.groovy.util.AbstractConcurrentMapBase$Segment[], value:
org.codehaus.groovy.reflection.GroovyClassValuePreJava7$GroovyClassValuePreJava7Segment
#5
<- segments - class:
org.codehaus.groovy.reflection.GroovyClassValuePreJava7$GroovyClassValuePreJava7Map,
value: org.codehaus.groovy.util.AbstractConcurrentMapBase$Segment[] #2
<- map - class:
org.codehaus.groovy.reflection.GroovyClassValuePreJava7, value:
org.codehaus.groovy.reflection.GroovyClassValuePreJava7$GroovyClassValuePreJava7Map
#1
<- globalClassValue - class:
org.codehaus.groovy.reflection.ClassInfo, value:
org.codehaus.groovy.reflection.GroovyClassValuePreJava7 #1
<- [8080] - class: java.lang.Object[], value:
org.codehaus.groovy.reflection.ClassInfo class ClassInfo
<- elementData - class: java.util.Vector, value:
java.lang.Object[] #78509
<- classes - class: org.apache.catalina.loader.WebappClassLoader,
value: java.util.Vector #242
{noformat}
Can we do something about them for 2.4.6? I'd try to help with a patch but I'm
afraid that this part of the Groovy code is still over my head.
was (Author: jkemnade):
I'm also experiencing those leaks. Can we do something about them for 2.4.6?
I'd try to help with a patch but I'm afraid that this part of the Groovy code
is still over my head.
> 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)
