[ https://issues.apache.org/jira/browse/GROOVY-11729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18014461#comment-18014461 ]
Saravanan Subiramaniam commented on GROOVY-11729: ------------------------------------------------- [~emilles] Yes, since setting the call site cache size to 0 has performance implications, we've decided not to go with this option. We would benefit from not caching the return value of method invocations (as mentioned in the description the objects returned such as RepeatableWriteUnitOfWork are huge and they occupy significant portion of the heap size). Is there a reason why the returned value of method is cached, can this be fixed? > 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)