[
https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15066871#comment-15066871
]
John Wagenleitner commented on GROOVY-7683:
-------------------------------------------
With {{GroovyClassValuePreJava7}} I don't think
{{GroovyClassValue.remove(Class)}} is designed to be called directly, I think
it would be enough if the cached Entry in the ManagedConcurrentMap was
collected due to its weakly held key (Class) being collected. I believe the
issue is that the cached value in the map (ClassInfo) stores a [strong
reference to the cached key
(Class)|https://github.com/apache/groovy/blob/73f5979a468f1508134eba20ce503630b0fe0cc7/src/main/org/codehaus/groovy/reflection/ClassInfo.java#L47].
So I don't think the Entry ever gets cleared. I think changing this to a
weak ref would allow the cache entry to be cleared, but hard to tell what
problems that might cause or if it would ever be possible for the Class to be
collected while the ClassInfo is used causing the weak ref to return null for
the Class.
I also think the
[ClassInfoCleanup|https://github.com/apache/groovy/blob/73f5979a468f1508134eba20ce503630b0fe0cc7/src/main/org/codehaus/groovy/reflection/ClassInfo.java#L77]
is not [doing what it's expected to do for
cleanup|https://github.com/apache/groovy/blob/73f5979a468f1508134eba20ce503630b0fe0cc7/src/main/org/codehaus/groovy/reflection/ClassInfo.java#L477-L489].
Since it's not stored it goes out of scope immediately and will be collected
long before the ClassInfo it's meant to clean up after is eligible for
collection.
I'm not familiar with this part of the code, so might be way 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
> 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)
