[ https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15447782#comment-15447782 ]
Andrew Garcia commented on GROOVY-7683: --------------------------------------- Linking to Groovy-7623 as it claims to be a possible solution path to this memory leak 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 > Attachments: > 0001-GROOVY-7683-replace-hard-reference-from-ClassInfo-to.patch, Screen Shot > 2016-08-16 at 10.53.04 PM.png > > > 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)