[
https://issues.apache.org/jira/browse/GROOVY-12558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18134390#comment-18134390
]
ASF GitHub Bot commented on GROOVY-12558:
-----------------------------------------
jdaugherty opened a new pull request, #3086:
URL: https://github.com/apache/groovy/pull/3086
GROOVY-12191 scoped call-site invalidation to the receiver's class, and a
change to a metaclass retires the domain of the class it belongs to. A receiver
can use the metaclass of another class: Spock's `Mock()` and many proxy
libraries generate a subclass whose `getMetaClass()` answers the metaclass of
the type it stands in for. Changing that metaclass, such as replacing an
`ExpandoMetaClass` method, retired only the stood-in type's domain, the
metaclass guard still saw the same instance, and the call site kept invoking
the replaced method. Groovy 5's global `SwitchPoint` re-linked it.
When the selected metaclass belongs to a class other than the receiver's,
`Selector` and `IndyCompoundAssign` now also capture that class's `SwitchPoint`
before selection and guard the site with it.
`IndyInvalidation.foreignMetaClassSwitchPointFor()` answers that switch point,
or `null` when the metaclass belongs to the receiver's own class, so an
ordinary call site gets no extra guard.
`org.codehaus.groovy.vmplugin.v8.IndyForeignMetaClassSwitchPointTest` gives
a subclass instance the `ExpandoMetaClass` of its superclass, replaces a method
on it between two calls of the same site, once for a method call and once for a
`+=` compound assignment, and expects the replacement each time. It fails
without the fix.
- Jira: [GROOVY-12558](https://issues.apache.org/jira/browse/GROOVY-12558)
- Reproducer:
https://github.com/jdaugherty/groovy-indy-shared-metaclass-switchpoint-reproducer
- Backport to `GROOVY_6_0_X`:
https://github.com/jdaugherty/groovy/commit/db6f007d8cecf67b5c1fbe16fe5c008d7917703d,
on the branch
[`GROOVY-12558-6_0_X`](https://github.com/jdaugherty/groovy/tree/GROOVY-12558-6_0_X).
It reproduces on 6.0.0 and master with invokedynamic; 5.1.3, and Groovy 6
with classic call sites, are not affected, so there is no 5.x backport. Could
this be backported to 6.0.x once it is merged?
> Indy: call site keeps a method replaced on a metaclass the receiver shares
> with another class
> ---------------------------------------------------------------------------------------------
>
> Key: GROOVY-12558
> URL: https://issues.apache.org/jira/browse/GROOVY-12558
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 6.0.0
> Reporter: James Daugherty
> Priority: Major
>
> On Groovy 6 with invokedynamic, a call site whose receiver uses the metaclass
> of another class keeps invoking a method after that metaclass replaces it.
> Groovy 5, and Groovy 6 with classic call sites, invoke the replacement. This
> is a regression from GROOVY-12191 (6.0.0-beta-1).
> Such receivers are common in tests: Spock's {{Mock()}} generates a subclass
> of the mocked type whose {{getMetaClass()}} answers the mocked type's
> metaclass, so a feature that replaces a method on the mock's metaclass
> changes the {{ExpandoMetaClass}} of the mocked type, and many proxy libraries
> behave the same way. A specification that replaces such a method in one
> feature and runs the same code under test in a later feature gets the earlier
> feature's closure: a {{0 * collaborator.update(*_)}} interaction fails with
> "Too many invocations", or an expected exception is never thrown.
> *Reproducer:*
> https://github.com/jdaugherty/groovy-indy-shared-metaclass-switchpoint-reproducer
> ({{./run.sh 5.1.3 6.0.0}}). {{GreeterProxy extends Greeter}} and is given
> the {{ExpandoMetaClass}} of {{Greeter}}, as a mock or proxy subclass is. One
> call site invokes {{greet()}} and one {{+=}} site invokes {{plus()}}; each
> method is replaced on the metaclass between two calls of the same site:
> {noformat}
> == Groovy 5.1.3
> indy=true: method call after replacing the method: second (OK)
> indy=true: compound assignment after replacing plus: second (OK)
> == Groovy 6.0.0
> indy=true: method call after replacing the method: first (STALE: the
> call site still invokes the replaced method)
> indy=true: compound assignment after replacing plus: first (STALE: the
> call site still invokes the replaced method)
> indy=false: method call after replacing the method: second (OK)
> indy=false: compound assignment after replacing plus: second (OK)
> {noformat}
> *Cause:* GROOVY-12191 replaced the global indy SwitchPoint with per-class
> domains. A call site is guarded by the SwitchPoint of the receiver's class
> ({{Selector.MethodSelector.captureTokenAndGetMetaClass()}},
> {{IndyInvalidation.classSwitchPointFor(args[0])}}; likewise in
> {{IndyCompoundAssign.resolve}}). A change to a metaclass retires the domain
> of the class the metaclass belongs to, {{MetaClass.getTheClass()}}
> ({{IndyInvalidation.switchPointForMetaClass}} / {{invalidateMetaClass}}).
> When the receiver's class is not the metaclass's class, as for
> {{GreeterProxy}} and the {{Greeter}} metaclass it uses, the change retires
> {{Greeter}}'s domain while the site waits on {{GreeterProxy}}'s. The receiver
> metaclass guard ({{SAME_MC}}) does not catch it either, because replacing an
> {{ExpandoMetaClass}} method keeps the same metaclass instance.
> *Proposed fix:* when the selected metaclass belongs to a class other than the
> receiver's, also capture that class's SwitchPoint before selection and guard
> the site with both. That applies to {{Selector}} and to
> {{IndyCompoundAssign}}, which captures its token the same way. A patch with
> tests follows as a pull request against master, with a backport for the 6.0.x
> line.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
