[GROOVY-7683] Memory leak when using Groovy as JSR-223 scripting language.

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.4.5
• Fix Version/s: 2.4.8
• Component/s: GroovyScriptEngine
• Labels: jsr-223
• Environment: OS: tested on Mac OS X El Capitan and Windows 10.; JVM: tested on 1.8.0_60 and 1.8.0_65.
• Flags: Important
• Assignee: John Wagenleitner
• Reporter: Arkadiusz Gasinski
• Created: 23/Nov/15 14:56
• Updated: 23/May/17 10:13
• Resolved: 11/Sep/16 04:03

Description

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. 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 project and run:

mvn test

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

mvn -Dlanguage=javascript test

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.

Any workarounds for this issue would be greatly appreciated.

Issue Links

• is related to: GROOVY-8189 OutOfMemoryError with groovy.use.classvalue=false
• is related to: GROOVY-7623 IBM Java (J9) ClassValue works correctly so should use it by default
• is related to: GROOVY-7646 Classes generated by Eval() never collected from Permgen/Metaspace
• is related to: GROOVY-8199 Re-enable use of ClassValue for all JDKs
• relates to: GROOVY-7109 Severe Memory Leak Happens when Script Executes
• relates to: GROOVY-7731 OutOfMemoryError starting from groovy-2.4.5 version.
• relates to: GROOVY-7913 ClassInfo.globalClassValue lead to GroovyClassLoader can't unload classes
• links to: GitHub Pull Request #219