[
https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15067764#comment-15067764
]
ASF GitHub Bot commented on GROOVY-7683:
----------------------------------------
GitHub user jwagenleitner opened a pull request:
https://github.com/apache/groovy/pull/219
GROOVY-7683 - Memory leak when using Groovy as JSR-223 scripting language
I am unsure what if any problems making the Class a `WeakReference` might
have but thought I'd put this out there for review.
I also tested against
[GROOVY-7646](https://issues.apache.org/jira/browse/GROOVY-7646) which was
consistently throwing OOME after <2 mins prior to these changes and ran to
completion with changes.
Another thing I noticed in looking at this class is that [uses a
`PhantomReference`](https://github.com/apache/groovy/blob/73f5979a468f1508134eba20ce503630b0fe0cc7/src/main/org/codehaus/groovy/reflection/ClassInfo.java#L405)
and attempts [to use the value from
`get()`](https://github.com/apache/groovy/blob/73f5979a468f1508134eba20ce503630b0fe0cc7/src/main/org/codehaus/groovy/reflection/ClassInfo.java#L435).
However, this will always return `null` so the code path never executes.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/jwagenleitner/groovy GROOVY-7683
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/groovy/pull/219.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #219
----
commit 10689a29cbf167c40b05c38aa5c144724045eeb0
Author: John Wagenleitner <[email protected]>
Date: 2015-12-17T00:44:29Z
GROOVY-7683 - Memory leak when using Groovy as JSR-223 scripting language
----
> 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)
