[
https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
> 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)
