[
https://issues.apache.org/jira/browse/GROOVY-11775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18038483#comment-18038483
]
Björn Kautler edited comment on GROOVY-11775 at 11/14/25 11:43 PM:
-------------------------------------------------------------------
> I don't have a great way to test this. I pushed to my local and ran the spock
> tests. However, this was a once-in-a-while condition and the tests OOM for me
> either way.
Actually, with the root cause in mind now, 100% reproduction and testing should
be trivial:
https://groovyconsole.dev/?g=groovy_4_0&codez=eNpLzkksLlZwy89XqOZSUEhJTVMoLkksSVWwVchLLVcISsxLyc_V0NTLS60o8cwr0dDkquVKBmtxSiwCaqnlAtJ6uZkVmXkaQEM0uUAmJAGlIPqBkkAtBUWZeSU5eRpAcT2w6ViF0AwiThMAgoI_-w
{code:groovy}
class Foo {
def state = new Random().nextInt()
}
class Bar {
}
Bar.mixin(Foo)
def bar = new Bar()
println(bar.state)
println(bar.state)
Bar.mixin(Foo)
println(bar.state)
println(bar.state)
{code}
Without your fix first two print the same, last two print the same, but first
and last two print different ones.
With your fix, all four should print the same.
was (Author: vampire):
> I don't have a great way to test this. I pushed to my local and ran the spock
> tests. However, this was a once-in-a-while condition and the tests OOM for me
> either way.
Actually, with the root cause in mind now, 100% reproduction and testing should
be trivial:
https://groovyconsole.dev/?g=groovy_4_0&codez=eNpLzkksLlZwy89XqOZSUEhJTVMoLkksSVWwVchLLVcISsxLyc_V0NTLS60o8cwr0dDkquVKBmtxSiwCaqnlAtJ6uZkVmXkaQEM0uUAmJAGlIPqBkkAtBUWZeSU5eRpAcT2w6ViF0AwiThMAgoI_-w
[code:groovy}
class Foo {
def state = new Random().nextInt()
}
class Bar {
}
Bar.mixin(Foo)
def bar = new Bar()
println(bar.state)
println(bar.state)
Bar.mixin(Foo)
println(bar.state)
println(bar.state)
{code}
Without your fix first two print the same, last two print the same, but first
and last two print different ones.
With your fix, all four should print the same.
> 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
> Assignee: Eric Milles
> Priority: Major
> Attachments: StarTrekPatrickStewartGIF.gif
>
>
> 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)
