[jira] [Updated] (GROOVY-11775) Stateful runtime mixins sometimes do not work properly

["Björn Kautler (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GROOVY-11775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Björn Kautler updated GROOVY-11775:
-----------------------------------
    Description: 
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 and 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.

  was:
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.


> 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 and 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)