[
https://issues.apache.org/jira/browse/GROOVY-8092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15886363#comment-15886363
]
Jochen Theodorou commented on GROOVY-8092:
------------------------------------------
> I do not recall trying those particular flags but anyway I cannot see what
> they have to do with SoftReference collection.
they ensure garbage collection will handle unloading classes more aggressively.
This does not help with SoftReference in general, but it helps with a
SoftReference to a Class.
> Well better still be to not hold on to any (non-weak) references to a
> GroovyClassLoader from static fields in Groovy to begin with!
Class will always hold a reference, that is not weak to a class loader. So we
have to go back a step, and then we are at the meta class not holding a
non-weak reference at an arbitrary class. The same for MetaMethod and
MetaProperty and in the end also for MetaMethodIndex. That is far from trivial
to do actually.
> Sorry, I am not following your argument at all. Currently GroovyClassLoader
> instances are softly reachable, with a root reference chain starting in
> Groovy code; and the Java 8 VM with default settings will not collect it
> (even after System.gc()) until you force it to throw an OutOfMemoryError by
> allocating giant arrays. If you use reflection to null out all the soft
> references (leaving it only weakly reachable) then it is collected on the
> next GC cycle. This is easily and consistently reproducible in an automated
> test, and consistent with the very loose constraints defined in Javadoc.
A GroovyClassLoder not referenced by you anymore should normally have the same
effect, or not? But it does not
>> replacing the SoftReference with a hard one will actually increase the
>> problem
> I think John Wagenleitner’s proposal was to use a strong reference only when
> the class being inspected is already visible to Groovy’s own loader—for
> example, something in Java Platform—and otherwise use a weak reference. This
> would certainly solve the leak, at the expense of recalculating ClassInfo
> metadata too often under memory pressure.
yes, can´t have both.
> As noted in JDK-6389107 (filed by me years ago in a different context),
> without better Java Platform support there is no perfect solution in general.
> In this case we can actually do better, because most of the problematic
> classes will in fact be loaded by a GroovyClassLoader, which is code
> controlled by Groovy itself. Thus the best algorithm would be to keep a
> metadata cache as an instance field in GroovyClassLoader (probably irrelevant
> that InnerLoader is actually the defining loader, since that is a
> GroovyClassLoader too), and:
>
> * determine the defining loader of the class being inspected
> * if an ancestor of the loader of Groovy itself, use a strong reference
> * if a GroovyClassLoader, use a strong reference but keep the initial
> lookup map in the newly introduced field
> * otherwise use a weak reference
hmm... the part with the ancestors I guess I can be ok with. the last two
points, not sure. Basically you tell me to put the meta classes into the
GroovyClassLoader and make ClassInfos weak references in those cases. I think
it is indeed something should investigate. The big question is for me, what
scenarios are left in which Groovy has to handle classes coming from a loader
child to the class loader, that loaded Groovy, and in which the loader is not a
GroovyClassLoader. I feel like there are still many cases, but most usages
would be different. And then the question is if the meta class recreation is
acceptable for those. Still worth trying imho. And then there is the case of a
totally unrelated loader...
Actually thinking of Java9 where I think each module has its own loader and you
basically have multiple parents... not sure the idea still holds up there.
Another such environment is of course anything with OSGI.... Still I think
there should be a configuration option for the strategy you mentioned
> Compatibility issues between groovy 2.4.8 and jenkins workflow-cps-plugin
> 2.23
> -------------------------------------------------------------------------------
>
> Key: GROOVY-8092
> URL: https://issues.apache.org/jira/browse/GROOVY-8092
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
> Affects Versions: 2.4.8
> Environment: Jenkins 2.19-stable with a single commit that bumps
> groovy 2.4.8
> workflow-cps-plugin 2.23
> Reporter: Ion Alberdi
>
> Created the issue on jenkins first
> https://issues.jenkins-ci.org/browse/JENKINS-42189
> Creating it here, in case the fix may be developed in groovy itself.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
