[
https://issues.apache.org/jira/browse/GROOVY-10773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Val E updated GROOVY-10773:
---------------------------
Description:
It looks like method handles caching is creating memory leaks in Groovy 4,
because it is also storing the results of method execution in addition to the
method handle in
*_org.codehaus.groovy.vmplugin.v8.CacheableCallSite.latestHitMethodHandleWrapper_*
These cached method handles are not subject to garbage collection. However, it
is also storing the result of the method execution that can be any arbitrary
object, which will also prevent the object itself and 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. I 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!
was:
It looks like method handles caching is creating memory leaks in Groovy 4,
because it is also storing the results of method execution as well as the
method handle in
*_org.codehaus.groovy.vmplugin.v8.CacheableCallSite.latestHitMethodHandleWrapper_*
These cached method handles are not subject to garbage collection. However, it
is also storing the result of the method execution that can be any arbitrary
object, which will also prevent the object itself and 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. I 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!
> Groovy 4 memory leak due 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.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, visualvm_mem_sampler.png
>
>
> It looks like method handles caching is creating memory leaks in Groovy 4,
> because it is also storing the results of method execution in addition to the
> method handle in
> *_org.codehaus.groovy.vmplugin.v8.CacheableCallSite.latestHitMethodHandleWrapper_*
>
> These cached method handles are not subject to garbage collection. However,
> it is also storing the result of the method execution that can be any
> arbitrary object, which will also prevent the object itself and 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. I 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)
