[
https://issues.apache.org/jira/browse/GROOVY-10773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-10773:
-------------------------------
Attachment: screenshot-2.png
> Groovy 4 memory leak due to presumptuous caching in
> org.codehaus.groovy.vmplugin.v8.CacheableCallSite
> -----------------------------------------------------------------------------------------------------
>
> Key: GROOVY-10773
> URL: https://issues.apache.org/jira/browse/GROOVY-10773
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 4.0.5
> Environment: Java 1.8, 11, 14
> Groovy 4.0.3 4.0.4, 4.0.5
> Reporter: Val E
> Priority: Major
> Attachments: MemLeakContainer.groovy, MemLeakItem.groovy,
> MemLeakTest.zip, TestScript.groovy, build.gradle, heapdump.png,
> image-2022-09-29-13-21-57-256.png, image-2022-09-30-11-01-13-234.png,
> image-2022-09-30-11-05-57-860.png, image-2022-09-30-11-24-49-168.png,
> screenshot-1.png, screenshot-2.png, visualvm_mem_sampler.png
>
>
> 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.
> !image-2022-09-29-13-21-57-256.png|width=471,height=421!
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
