[
https://issues.apache.org/jira/browse/GROOVY-11729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18014686#comment-18014686
]
Jochen Theodorou commented on GROOVY-11729:
-------------------------------------------
[~saravanan.subiramaniam] groovy.indy.callsite.cache.size controls a cache
size for the method selection, not for method results.
> 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)
