Saravanan Subiramaniam created GROOVY-11729:
-----------------------------------------------
Summary: 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
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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
