[jira] [Commented] (GROOVY-7683) Memory leak when using Groovy as JSR-223 scripting language.
[ https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15527902#comment-15527902 ] John Wagenleitner commented on GROOVY-7683: --- Not sure, but there's been some talk about it on the dev mailing list which is usually a sign that it's not too far off. > 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 >Assignee: John Wagenleitner > Labels: jsr-223 > Fix For: 2.4.8 > > 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 > 2 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)
[jira] [Commented] (GROOVY-7683) Memory leak when using Groovy as JSR-223 scripting language.
[ https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15481100#comment-15481100 ] Andrew Garcia commented on GROOVY-7683: --- Any idea when the expected 2.4.8 release date is? > 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 >Assignee: John Wagenleitner > Labels: jsr-223 > Fix For: 2.4.8 > > 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 > 2 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)
[jira] [Commented] (GROOVY-7683) Memory leak when using Groovy as JSR-223 scripting language.
[ https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15480909#comment-15480909 ] ASF GitHub Bot commented on GROOVY-7683: Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/219 > 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 > 2 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)
[jira] [Commented] (GROOVY-7683) Memory leak when using Groovy as JSR-223 scripting language.
[ https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15449142#comment-15449142 ] Andrew Garcia commented on GROOVY-7683: --- Also linking because I added a walkthrough on how I got that JDK to play nice with my grails project. > 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 > 2 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)
[jira] [Commented] (GROOVY-7683) Memory leak when using Groovy as JSR-223 scripting language.
[ https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 > 2 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)
[jira] [Commented] (GROOVY-7683) Memory leak when using Groovy as JSR-223 scripting language.
[ https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15420705#comment-15420705 ] Veit Guna commented on GROOVY-7683: --- Any news on this? I also encountered the mentioned problem, that MetaMethodIndex$Entry classes are growing quickly without being able to be GCed. My scenario is during loadtests on the client side. I use restassured 2.9.0 (uses groovy 2.4.6) to perform json parsing. I could track it down to this little snippet to reproduce the behavior: {code} ... import com.jayway.restassured.path.json.JsonPath; ... public static void main(String[] args) throws InterruptedException { for (int ci = 0; ci < 10; ci++) { JsonPath.from("{\"id\": \"" + UUID.randomUUID().toString() + "\"}").getUUID("id"); Thread.sleep(1); } } {code} Simply take a look using jvisualvm and you see the results. I also tried the latest 2.4.x groovy version and latest 2.3.x with the same results. > 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 > 2 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)
[jira] [Commented] (GROOVY-7683) Memory leak when using Groovy as JSR-223 scripting language.
[ https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15268014#comment-15268014 ] ASF GitHub Bot commented on GROOVY-7683: Github user jwagenleitner commented on a diff in the pull request: https://github.com/apache/groovy/pull/219#discussion_r61834705 --- Diff: src/main/org/codehaus/groovy/util/ManagedReference.java --- @@ -46,7 +46,6 @@ public final T get() { public final void clear() { ref.clear(); -manager.removeStallEntries(); --- End diff -- Thanks for reviewing that other PR. I merged that PR and will rebase this and leave the call to manager.removeStallEntries(). > 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 > 2 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)
[jira] [Commented] (GROOVY-7683) Memory leak when using Groovy as JSR-223 scripting language.
[ https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 WeakReferenceklazz; --- 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 > 2 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)
[jira] [Commented] (GROOVY-7683) Memory leak when using Groovy as JSR-223 scripting language.
[ https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15266951#comment-15266951 ] ASF GitHub Bot commented on GROOVY-7683: Github user jwagenleitner commented on a diff in the pull request: https://github.com/apache/groovy/pull/219#discussion_r61764947 --- 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 WeakReferenceklazz; --- End diff -- That's the question I've struggled with too. My assumption here is that only the Groovy Runtime should ever ask for ClassInfo objects and in most places I can find they do so either with a Class or an instance of the Class which I think would mean it wouldn't have been collected. But it's been difficult for me to be certain that the case can never happen. Best I can think of is maybe check if the ref is null and throw a `GroovyBugError`. > 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 > 2 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)
[jira] [Commented] (GROOVY-7683) Memory leak when using Groovy as JSR-223 scripting language.
[ https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15266940#comment-15266940 ] ASF GitHub Bot commented on GROOVY-7683: Github user jwagenleitner commented on a diff in the pull request: https://github.com/apache/groovy/pull/219#discussion_r61764022 --- Diff: src/main/org/codehaus/groovy/util/ManagedReference.java --- @@ -46,7 +46,6 @@ public final T get() { public final void clear() { ref.clear(); -manager.removeStallEntries(); --- End diff -- `ClassInfo#finalizeReference` calls `setStrongMetaClass(null)` which in turn calls `replaceWeakMetaClassRef(null)` which calls `weakRef#clear` which is on ManagedReference. This causes a recursive call back into the queue can can lead to stackoverflow if there are lots of ClassInfo ManagedReferences in the Reference Queue. A related PR that attempts to prevent this reentrant processing is PR #298. > 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 > 2 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)
[jira] [Commented] (GROOVY-7683) Memory leak when using Groovy as JSR-223 scripting language.
[ https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15266912#comment-15266912 ] 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_r61761881 --- 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 WeakReferenceklazz; --- End diff -- I wonder what we should do if the referenced class has been collected. At least in the non - ClassValue version, it might be, that the ClassInfo still exists. And if then somebody tries to get the meta class using that ClassInfo things will blow up > 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 > 2 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)
[jira] [Commented] (GROOVY-7683) Memory leak when using Groovy as JSR-223 scripting language.
[ https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15266908#comment-15266908 ] 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_r61761426 --- Diff: src/main/org/codehaus/groovy/util/ManagedReference.java --- @@ -46,7 +46,6 @@ public final T get() { public final void clear() { ref.clear(); -manager.removeStallEntries(); --- End diff -- Why did you remove this call? > 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 > 2 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)
[jira] [Commented] (GROOVY-7683) Memory leak when using Groovy as JSR-223 scripting language.
[ https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15060964#comment-15060964 ] John Wagenleitner commented on GROOVY-7683: --- I tested the referenced Github LeakTest project again and this time created some memory pressure after the loop by calling the following method: {code} // Create memory pressure to force soft reference collection private void createOOM() { Listbuffer = new ArrayList (100); int chunk = 128 * 1024 * 1024; int limit = 5; try { for (int i = 0; i < limit; i++) { buffer.add(new Long[chunk]); } } catch (OutOfMemoryError oom) { buffer.clear(); return; } throw new RuntimeException("OOM expected"); } {code} Using the default setting with {{ClassValue}} disabled things looked pretty much the same as before. However, enabling {{ClassValue}} by adding the following to the static initializer: {code} System.setProperty("groovy.use.classvalue", "true"); {code} Seemed to dramatically reduce the heap size. Size: 60mb vs 1.2G Classes: 2.6k vs 22.6k Objects: 1.5m vs 18.2m Class Loader: 6 vs 40k So I think [~blackdrag] original suggestion to try enabling ClassValue is worth a try. You might still see heap usage creep up over time but I would expect as memory pressure builds close to the 8G max you'll see GC work and should experience a lot less severe leak than without using it. > 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 > 2 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)
[jira] [Commented] (GROOVY-7683) Memory leak when using Groovy as JSR-223 scripting language.
[ https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15061672#comment-15061672 ] Jochen Kemnade commented on GROOVY-7683: Yes, the classes are properly cleaned up with {{groovy.use.classvalue=true}}, so I guess the problem must be in {{GroovyClassValuePreJava7}}. Err, this may be a stupid question, but, is {{GroovyClassValue.remove(Class)}} ever called? > 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 > 2 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)
[jira] [Commented] (GROOVY-7683) Memory leak when using Groovy as JSR-223 scripting language.
[ https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15060173#comment-15060173 ] Jochen Kemnade commented on GROOVY-7683: Oh, I read your comment too late. Yes, apparently it doesn't fix the problem. Maybe I misunderstood your comment about the hard references. > 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 > 2 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)