[
https://issues.apache.org/jira/browse/GROOVY-8092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15885988#comment-15885988
]
Jochen Theodorou commented on GROOVY-8092:
------------------------------------------
>> -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled could help here
> No, there is a JVM flag to set some timeout for SoftReference to one second
> or some such dummy value, which does help, but we cannot put the burden on
> users to tune their JVM with unsupported flags.
You mean no, they do not help if you use them or no, you cannot force people to
use them?
> So Jenkins forcibly clears the references when it is done with the
> GroovyClassLoader. This is the current code if you are interested.
I currently cannot check, but maybe it would be best to provide an official API
for this. That way you would not have to depend on internals. And since Gradle
is now doing something similar we have at least two big use cases for this.
[...]
> The Java Platform makes no real guarantees about what a SoftReference will
> do. As seen in our automated tests, in practice it will be collected only
> when some allocation attempt is made which actually throws OutOfMemoryError.
Well, the javadoc states this:
"""
Suppose that the garbage collector determines at a certain point in time that
an object is softly reachable. At that time it may choose to clear atomically
all soft references to that object and all soft references to any other
softly-reachable objects from which that object is reachable through a chain of
strong references. At the same time or at some later time it will enqueue those
newly-cleared soft references that are registered with reference queues.
All soft references to softly-reachable objects are guaranteed to have been
cleared before the virtual machine throws an OutOfMemoryError. Otherwise no
constraints are placed upon the time at which a soft reference will be cleared
or the order in which a set of such references to different objects will be
cleared. Virtual machine implementations are, however, encouraged to bias
against clearing recently-created or recently-used soft references.
""
When I say the GC does not do its job, I am talking about a soft reachable
class, marked as such and not removed before an OOME. Maybe I am wrong and
maybe the class was not marked, but at least on java7 I have seen behavior that
strongly suggests my assumption is right. And in all such cases changing to
Mark-And-Sweep helped. And if you say that is because the class has not been
marked as softly reachable, then the same problem will most likely appear with
weakly reachable ones. Afaik it is the same step in the GC. Which is why I
cannot come to the same conclusion as you, that a WeakReference is fine. They
are usually fine, because the objects are thrown away earlier. But on high
memory pressure, with many objects being created and destroyed you can have the
same problem. SoftReferences enforce this situation more, that is why they are
bad.
But changing the SoftReference to a WeakReference may solve the problem for
you, it will produce a new problem for us. ClassValue was supposed to close the
gap, and catastrophically failed to do so. And replacing the SoftReference with
a hard one will actually increase the problem.. can still make sense in
certain, very specific cases, as John was explaining.
And I have to ask what is left? Nothing but the cleanup API imho.
> 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)
