groovy-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Garcia (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (GROOVY-7683) Memory leak when using Groovy as JSR-223 scripting language.
Date Tue, 30 Aug 2016 02:35:20 GMT

    [ 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)

Mime
View raw message