[
https://issues.apache.org/jira/browse/GROOVY-11729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18015573#comment-18015573
]
Saravanan Subiramaniam commented on GROOVY-11729:
-------------------------------------------------
[~emilles] GroovyAwareListMetaClass is a custom DelegatingMetaClass, indeed
implemented as an inner class which uses the data from the outer class
(GroovyAwareList). The issue still persists when GroovyAwareListMetaClass is
made static class. When we remove GroovyAwareListMetaClass, the issue is not
observed. So, we are evaluating if we can remove GroovyAwareListMetaClass and
implement the custom methods behavior in GroovyAwareList itself.
> 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)
