[
https://issues.apache.org/jira/browse/GROOVY-11775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18029339#comment-18029339
]
Eric Milles commented on GROOVY-11775:
--------------------------------------
The design of the map from object instance to mixin instance, using soft
reference for key and strong reference for value, is that as long as your
object instance is reachable, the mixin instance will be available. From
javadoc of SoftReference: "As long as the referent of a soft reference is
strongly reachable, that is, is actually in use, the soft reference will not be
cleared."
I'm not sure from your description how you are keeping instances of B or C.
> Stateful runtime mixins sometimes do not work properly
> ------------------------------------------------------
>
> Key: GROOVY-11775
> URL: https://issues.apache.org/jira/browse/GROOVY-11775
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 4.0.26
> Reporter: Björn Kautler
> Priority: Major
>
> I have class {{A}} and class {{B}}.
> I {{mixin}} {{A}} to {{B}} using {{B.mixin(A)}}.
> {{A}} has a property {{X}}.
> Now I have a method {{M}} in a subclass of {{B}} which first calls a method
> {{N}} of {{A}}, then another method {{O}} of {{A}}.
> Both calls happen linearly, both happen on the same thread, yet occasionally
> the call to {{O}} hits a different instance of {{A}} than the call to {{N}}
> and thus {{N}} and {{O}} work on a different instance of the field in {{A}}.
> From a quick look at the code an debug, the problem might maybe be, that the
> {{MixinInMetaClass#managedIdentityConcurrentMap}} holds the {{B}} instances
> that serve as key in soft references. So maybe if the heap gets exhausted
> between calling {{N}} and {{O}}, the map entry is nuked by the garbage
> collector and thus the {{O}} call creates a new {{A}} instance.
> If this is the case (or actually whatever else causes what I see), stateful
> runtime mixins are quite flaky and should not be used unless this is fixed,
> as you cannot rely on the state. Actually, I was not able to knit an MCVE by
> intentionally triggering two OOME between the calls to {{N}} and {{O}}, so my
> suspicion about the cause might not be correct.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
