[GROOVY-10773] Groovy 4 memory leak due to presumptuous caching in org.codehaus.groovy.vmplugin.v8.CacheableCallSite

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 4.0.5
• Fix Version/s: 4.0.7
• Environment: Java 1.8, 11, 14 ; Groovy 4.0.3 4.0.4, 4.0.5
• Flags: Important

Language

groovy

• Assignee: Paul King
• Reporter: Val E
• Created: 29/Sep/22 17:22
• Updated: 10/Feb/23 21:40
• Resolved: 04/Jan/23 01:31

Description

It looks like method handles caching is creating memory leaks in Groovy 4, because in addition to the method handle it is also storing the results of the  method execution in org.codehaus.groovy.vmplugin.v8.CacheableCallSite.latestHitMethodHandleWrapper

 

These cached method handles are not subject to garbage collection. Since the cached handler is also storing the result of the method execution, which can be any arbitrary object, it will also prevent the object itself and any of its transitive properties from being garbage collected. In our case the method execution often produced very large maps which caused our prod servers to very quickly bog down and need restarts.

 

I have tried this with Groovy 4.0.4 and 4.0.5, as well as Java 1.8, 11, and 14; all produced this memory leaks.

However Groovy 3.0.5 did NOT produce this leak.

 

I have attached a very simple Gradle project. It produces 5000 MemoryLeakItem objects. Nothing special about these objects themselves, just easy to find in VisualVM and heap dumps. A container object that does some basic dynamic method resolution via a methodMissing and a TestScript to run and pause execution, so a heap dump can be created or VisualVM inspected.

 

To reproduce the leak:

Run TestScript.groovy, and when it pauses for keyboard input, check VisualVM or a heap dump.

 

 

Issue Links

• relates to: GROOVY-10772 Possible memory leak, CacheableCallSite retains objects across invocations