You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@groovy.apache.org by "Eric Milles (Jira)" <ji...@apache.org> on 2025/10/12 22:26:00 UTC
[jira] [Closed] (GROOVY-11729) Increase in heap memory caused by org.codehaus.groovy.vmplugin.v8.CacheableCallSite.latestHitMethodHandleWrapperSoftReference
[ https://issues.apache.org/jira/browse/GROOVY-11729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Eric Milles closed GROOVY-11729.
--------------------------------
Resolution: Information Provided
> 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: Bug
> 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)