[
https://issues.apache.org/jira/browse/GROOVY-12491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Murphy Heiberg updated GROOVY-12491:
------------------------------------------
Description:
When a class implements a trait, {{TraitComposer.applyTrait}} adds
{{Helper.$init$(this)}} to the class's object initializer without a method
target (the {{$static$init$}} call beside it has one). Every constructor
therefore dispatches the call through the meta class of the helper, even in
{{@CompileStatic}} classes:
{code:groovy}
trait Greeting { String greeting = 'hello' }
@CompileStatic class StaticGreeter implements Greeting {}
class DynamicGreeter implements Greeting {}
{code}
* {{StaticGreeter.<init>}}: {{ldc Greeting$Trait$Helper; ldc "$init$"; ...
invokestatic ScriptBytecodeAdapter.invokeMethodN}}
* {{DynamicGreeter.<init>}}: {{invokedynamic
invoke:(Class,LDynamicGreeter;)Object}}
* the static initializer of both: {{invokestatic
Greeting$Trait$Helper.$static$init$(Class)}}
This costs a dynamic dispatch on every instantiation. A GraalVM native image
has to register every trait helper's {{$init$}} for reflection, or construction
fails with "No signature of static method: $init$".
Proposed fix: give the {{$init$}} call its method target, the
{{$init$(TraitType)}} method the helper declares, so constructors call it with
{{invokestatic}} in dynamic, {{@TypeChecked}} and {{@CompileStatic}} classes.
The initializers of final trait fields ({{$init$<field>}},
{{$static$init$<field>}}) get their method targets too, and a helper that does
not declare {{$init$(TraitType)}} fails compilation with a {{GroovyBugError}}.
With this change a method added to the helper's meta class (for example with
ExpandoMetaClass) no longer replaces {{$init$}} or a field initializer, as it
already could not replace {{$static$init$}}. This includes the classes that
{{withTraits}} and {{as Trait}} generate at run time, which are composed the
same way.
PR: https://github.com/apache/groovy/pull/3025
was:
When a class implements a trait, {{TraitComposer.applyTrait}} adds
{{Helper.$init$(this)}} to the class's object initializer without a method
target (the {{$static$init$}} call beside it has one). Every constructor
therefore dispatches the call through the meta class of the helper, even in
{{@CompileStatic}} classes:
{code:groovy}
trait Greeting { String greeting = 'hello' }
@CompileStatic class StaticGreeter implements Greeting {}
class DynamicGreeter implements Greeting {}
{code}
* {{StaticGreeter.<init>}}: {{ldc Greeting$Trait$Helper; ldc "$init$"; ...
invokestatic ScriptBytecodeAdapter.invokeMethodN}}
* {{DynamicGreeter.<init>}}: {{invokedynamic
invoke:(Class,LDynamicGreeter;)Object}}
* the static initializer of both: {{invokestatic
Greeting$Trait$Helper.$static$init$(Class)}}
This costs a dynamic dispatch on every instantiation. A GraalVM native image
has to register every trait helper's {{$init$}} for reflection, or construction
fails with "No signature of static method: $init$".
Proposed fix: give the {{$init$}} call its method target, the
{{$init$(TraitType)}} method the helper declares, so constructors call it with
{{invokestatic}} in dynamic, {{@TypeChecked}} and {{@CompileStatic}} classes.
PR: https://github.com/apache/groovy/pull/3025
> Classes implementing a trait call the helper's $init$ through the meta class
> ----------------------------------------------------------------------------
>
> Key: GROOVY-12491
> URL: https://issues.apache.org/jira/browse/GROOVY-12491
> Project: Groovy
> Issue Type: Bug
> Components: Compiler, Static compilation
> Affects Versions: 6.0.0
> Reporter: Scott Murphy Heiberg
> Priority: Major
>
> When a class implements a trait, {{TraitComposer.applyTrait}} adds
> {{Helper.$init$(this)}} to the class's object initializer without a method
> target (the {{$static$init$}} call beside it has one). Every constructor
> therefore dispatches the call through the meta class of the helper, even in
> {{@CompileStatic}} classes:
> {code:groovy}
> trait Greeting { String greeting = 'hello' }
> @CompileStatic class StaticGreeter implements Greeting {}
> class DynamicGreeter implements Greeting {}
> {code}
> * {{StaticGreeter.<init>}}: {{ldc Greeting$Trait$Helper; ldc "$init$"; ...
> invokestatic ScriptBytecodeAdapter.invokeMethodN}}
> * {{DynamicGreeter.<init>}}: {{invokedynamic
> invoke:(Class,LDynamicGreeter;)Object}}
> * the static initializer of both: {{invokestatic
> Greeting$Trait$Helper.$static$init$(Class)}}
> This costs a dynamic dispatch on every instantiation. A GraalVM native image
> has to register every trait helper's {{$init$}} for reflection, or
> construction fails with "No signature of static method: $init$".
> Proposed fix: give the {{$init$}} call its method target, the
> {{$init$(TraitType)}} method the helper declares, so constructors call it
> with {{invokestatic}} in dynamic, {{@TypeChecked}} and {{@CompileStatic}}
> classes. The initializers of final trait fields ({{$init$<field>}},
> {{$static$init$<field>}}) get their method targets too, and a helper that
> does not declare {{$init$(TraitType)}} fails compilation with a
> {{GroovyBugError}}.
> With this change a method added to the helper's meta class (for example with
> ExpandoMetaClass) no longer replaces {{$init$}} or a field initializer, as it
> already could not replace {{$static$init$}}. This includes the classes that
> {{withTraits}} and {{as Trait}} generate at run time, which are composed the
> same way.
> PR: https://github.com/apache/groovy/pull/3025
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
