[
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 and noticed a significant
increase in heap memory.
For example, out of 2.3 GB heap space, 1.2 GB is occupied by
RepeatableWriteUnitOfWork - which in our case consists mainly of transactional
objects (from EclipseLink - as a result of JPQL).
This issue is similar to GROOVY-10773. We see 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}
Most of our methods perform DB queries, so there is no point in caching the
results of the methods. Why are the returned values from method cached in
{*}CacheableCallSite.latestHitMethodHandleWrapperSoftReference{*}?
Although it is SoftReference, these objects survive Full GC and the heap memory
is heavily occupied by these objects. Is there a way to disable caching the
returned value from the methods?
We did not run into this issue with Groovy 3. So, looking forward to
suggestions on how to address this and control the memory consumption.
was:
We recently upgraded Groovy from 3.x to 4.0.24 and noticed a significant
increase in heap memory. 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.
> 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 and noticed a significant
> increase in heap memory.
> For example, out of 2.3 GB heap space, 1.2 GB is occupied by
> RepeatableWriteUnitOfWork - which in our case consists mainly of
> transactional objects (from EclipseLink - as a result of JPQL).
> This issue is similar to GROOVY-10773. We see 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}
> Most of our methods perform DB queries, so there is no point in caching the
> results of the methods. Why are the returned values from method cached in
> {*}CacheableCallSite.latestHitMethodHandleWrapperSoftReference{*}?
> Although it is SoftReference, these objects survive Full GC and the heap
> memory is heavily occupied by these objects. Is there a way to disable
> caching the returned value from the methods?
> We did not run into this issue with Groovy 3. So, looking forward to
> suggestions on how to address this and control the memory consumption.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
