[
https://issues.apache.org/jira/browse/GROOVY-11729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Saravanan Subiramaniam updated GROOVY-11729:
--------------------------------------------
Description:
We recently upgraded Groovy from 3.x to 4.0.24 in our application and noticed
increase in heap memory in customer environments. For example, out of 2.3 GB
heap space, 1.2 GB is occupied by RepeatableWriteUnitOfWork - which is a
transactional stuff from EclipseLink. This issue is similar to GROOVY-10773.
We've 66K org.codehaus.groovy.vmplugin.v8.CacheableCallSite objects and the
total retained set of org.codehaus.groovy.vmplugin.v8.CacheableCallSite is 1.2
GB. Please see the paths to GC root (with all references) below:
{code:java}
class java.lang.invoke.LambdaForm$MH @ 0x74b360088 (System Class)
└── <resolved_references> java.lang.Object[6] @ 0x74b3600f8
└── [1] java.lang.invoke.BoundMethodHandle$Species_LLLLL @ 0x74b363940
└── argL4 java.lang.invoke.BoundMethodHandle$Species_LL @ 0x74b363c58
└── argL1 class
mycompany.dynamiclogic.MY_DYLO$_getDuplicateDetailsForPerson_closure2 @
0x77226a958
└── <resolved_references> java.lang.Object[172] @ 0x77591fd68
└── [66] org.codehaus.groovy.vmplugin.v8.CacheableCallSite
@ 0x775930328
└── latestHitMethodHandleWrapperSoftReference
java.lang.ref.SoftReference @ 0x789b7bd68
└── referent
org.codehaus.groovy.vmplugin.v8.MethodHandleWrapper @ 0x789b7bd90
└── cachedMethodHandle
java.lang.invoke.BoundMethodHandle$Species_LLLL @ 0x789b7bdb0
└── argL1
java.lang.invoke.MethodHandleImpl$CountingWrapper @ 0x789b7be20
└── target
java.lang.invoke.BoundMethodHandle$Species_LLLL @ 0x789b7be58
└── argL1
java.lang.invoke.MethodHandleImpl$CountingWrapper @ 0x789b7beb0
└── target
java.lang.invoke.BoundMethodHandle$Species_LLLL @ 0x789b7bee8
└── argL0
java.lang.invoke.BoundMethodHandle$Species_LL @ 0x789b7bf18
└── argL1
com.mycompany.dynlogic.components.GroovyAwareList$GroovyAwareListMetaClass @
0x789b7c0c0
└── this$0
com.mycompany.common.dynlogic.components.GroovyAwareList @ 0x789b7bf58
└──
BasePersistable com.mycompany.entities.MyEntityDomain @ 0x789b7c70c
└──
_persistence_listener
com.mycompany.support.eclipselink.MyAttributeChangeListener @ 0x789b7f958
└──
uow org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork @
0x781c25650 {code}
Why is the returned value from method is cached in
{*}CacheableCallSite.latestHitMethodHandleWrapperSoftReference{*}?
Although it is SoftReference, these objects survive Full GC and the heap memory
is heavily occupied by these objects. We've experienced that K8s kills the POD
as it reaches the memory limit and my guess is that the increase in heap space
contributes to the issue. Is there a way to skip caching the returned value
from the methods (or change it to WeakReference instead)?
We did not run into this issue with Groovy 3. So, looking forward to
suggestions on how to address this/keep the memory consumption low.
was:
We recently upgraded Groovy from 3.x to 4.0.24 in our application and noticed
increase in heap memory in customer environments. For example, out of 2.3 GB
heap space, 1.2 GB is occupied by RepeatableWriteUnitOfWork - which is a
transactional stuff from EclipseLink. This issue is similar to GROOVY-10773.
We've 66K org.codehaus.groovy.vmplugin.v8.CacheableCallSite objects and the
total retained set of org.codehaus.groovy.vmplugin.v8.CacheableCallSite is 1.2
GB. Please see the paths to GC root (with all references) below:
{code:java}
class java.lang.invoke.LambdaForm$MH @ 0x74b360088 (System Class)
└── <resolved_references> java.lang.Object[6] @ 0x74b3600f8
└── [1] java.lang.invoke.BoundMethodHandle$Species_LLLLL @ 0x74b363940
└── argL4 java.lang.invoke.BoundMethodHandle$Species_LL @ 0x74b363c58
└── argL1 class
mycompany.dynamiclogic.MY_DYLO$_getDuplicateDetailsForPerson_closure2 @
0x77226a958
└── <resolved_references> java.lang.Object[172] @ 0x77591fd68
└── [66] org.codehaus.groovy.vmplugin.v8.CacheableCallSite
@ 0x775930328
└── latestHitMethodHandleWrapperSoftReference
java.lang.ref.SoftReference @ 0x789b7bd68
└── referent
org.codehaus.groovy.vmplugin.v8.MethodHandleWrapper @ 0x789b7bd90
└── cachedMethodHandle
java.lang.invoke.BoundMethodHandle$Species_LLLL @ 0x789b7bdb0
└── argL1
java.lang.invoke.MethodHandleImpl$CountingWrapper @ 0x789b7be20
└── target
java.lang.invoke.BoundMethodHandle$Species_LLLL @ 0x789b7be58
└── argL1
java.lang.invoke.MethodHandleImpl$CountingWrapper @ 0x789b7beb0
└── target
java.lang.invoke.BoundMethodHandle$Species_LLLL @ 0x789b7bee8
└── argL0
java.lang.invoke.BoundMethodHandle$Species_LL @ 0x789b7bf18
└── argL1
com.mycompancy.dynlogic.components.GroovyAwareList$GroovyAwareListMetaClass @
0x789b7c0c0
└── this$0
com.mycompancy.common.dynlogic.components.GroovyAwareList @ 0x789b7bf58
└──
BasePersistable com.mycompancy.entities.MyEntityDomain @ 0x789b7c70c
└──
_persistence_listener
com.mycompancy.support.eclipselink.MyAttributeChangeListener @ 0x789b7f958
└──
uow org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork @
0x781c25650 {code}
Why is the returned value from method is cached in
{*}CacheableCallSite.latestHitMethodHandleWrapperSoftReference{*}?
Although it is SoftReference, these objects survive Full GC and the heap memory
is heavily occupied by these objects. We've experienced that K8s kills the POD
as it reaches the memory limit and my guess is that the increase in heap space
contributes to the issue. Is there a way to skip caching the returned value
from the methods (or change it to WeakReference instead)?
We did not run into this issue with Groovy 3. So, looking forward to
suggestions on how to address this/keep the memory consumption low.
> Increase in heap memory caused by
> org.codehaus.groovy.vmplugin.v8.CacheableCallSite.latestHitMethodHandleWrapperSoftReference
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: GROOVY-11729
> URL: https://issues.apache.org/jira/browse/GROOVY-11729
> Project: Groovy
> Issue Type: Question
> Affects Versions: 4.0.24
> Reporter: Saravanan Subiramaniam
> Priority: Major
>
> We recently upgraded Groovy from 3.x to 4.0.24 in our application and noticed
> increase in heap memory in customer environments. For example, out of 2.3 GB
> heap space, 1.2 GB is occupied by RepeatableWriteUnitOfWork - which is a
> transactional stuff from EclipseLink. This issue is similar to GROOVY-10773.
> We've 66K org.codehaus.groovy.vmplugin.v8.CacheableCallSite objects and the
> total retained set of org.codehaus.groovy.vmplugin.v8.CacheableCallSite is
> 1.2 GB. Please see the paths to GC root (with all references) below:
> {code:java}
> class java.lang.invoke.LambdaForm$MH @ 0x74b360088 (System Class)
> └── <resolved_references> java.lang.Object[6] @ 0x74b3600f8
> └── [1] java.lang.invoke.BoundMethodHandle$Species_LLLLL @ 0x74b363940
> └── argL4 java.lang.invoke.BoundMethodHandle$Species_LL @ 0x74b363c58
> └── argL1 class
> mycompany.dynamiclogic.MY_DYLO$_getDuplicateDetailsForPerson_closure2 @
> 0x77226a958
> └── <resolved_references> java.lang.Object[172] @ 0x77591fd68
> └── [66]
> org.codehaus.groovy.vmplugin.v8.CacheableCallSite @ 0x775930328
> └── latestHitMethodHandleWrapperSoftReference
> java.lang.ref.SoftReference @ 0x789b7bd68
> └── referent
> org.codehaus.groovy.vmplugin.v8.MethodHandleWrapper @ 0x789b7bd90
> └── cachedMethodHandle
> java.lang.invoke.BoundMethodHandle$Species_LLLL @ 0x789b7bdb0
> └── argL1
> java.lang.invoke.MethodHandleImpl$CountingWrapper @ 0x789b7be20
> └── target
> java.lang.invoke.BoundMethodHandle$Species_LLLL @ 0x789b7be58
> └── argL1
> java.lang.invoke.MethodHandleImpl$CountingWrapper @ 0x789b7beb0
> └── target
> java.lang.invoke.BoundMethodHandle$Species_LLLL @ 0x789b7bee8
> └── argL0
> java.lang.invoke.BoundMethodHandle$Species_LL @ 0x789b7bf18
> └── argL1
> com.mycompany.dynlogic.components.GroovyAwareList$GroovyAwareListMetaClass @
> 0x789b7c0c0
> └── this$0
> com.mycompany.common.dynlogic.components.GroovyAwareList @ 0x789b7bf58
> └──
> BasePersistable com.mycompany.entities.MyEntityDomain @ 0x789b7c70c
> └──
> _persistence_listener
> com.mycompany.support.eclipselink.MyAttributeChangeListener @ 0x789b7f958
> └──
> uow org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork @
> 0x781c25650 {code}
> Why is the returned value from method is cached in
> {*}CacheableCallSite.latestHitMethodHandleWrapperSoftReference{*}?
> Although it is SoftReference, these objects survive Full GC and the heap
> memory is heavily occupied by these objects. We've experienced that K8s
> kills the POD as it reaches the memory limit and my guess is that the
> increase in heap space contributes to the issue. Is there a way to skip
> caching the returned value from the methods (or change it to WeakReference
> instead)?
> We did not run into this issue with Groovy 3. So, looking forward to
> suggestions on how to address this/keep the memory consumption low.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
