Mailing-List: contact users-help@groovy.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@groovy.apache.org
MIME-Version: 1.0
In-Reply-To: <CADQzvmn24btWpAu+ncnqdJefLE6GG9vjkWam1D0oprPrkRR_KA@mail.gmail.com>
References: <CADgKzdxY7GeNetTRvSNaDNTkMcFqUEWTE-gxF0yS=j9wb98cyA@mail.gmail.com>
 <5C676E6359909E478C7B811BDB48CA356C498D@CWWAPP478.windstream.com>
 <CADgKzdzqfbpWVAvCkOwMZwRowPm_yDXY+kMHq1-nPQpPxdLRGg@mail.gmail.com>
 <CAMbkE7RqE1Erx8_LvjVbuaoNWFUMZXm6Fty4EBtgSSm31Zv4YQ@mail.gmail.com>
 <CADgKzdxEMqYng+hS=jT3PBqo5OV3YsV2K8TFjvO5rkvJ_KJsFw@mail.gmail.com>
 <CAAJdKXmBabCHgfU+53deWYcs_nrz-6992AasdvEBRnZ0pn7E8Q@mail.gmail.com> <CADQzvmn24btWpAu+ncnqdJefLE6GG9vjkWam1D0oprPrkRR_KA@mail.gmail.com>
From: Graeme Rocher <graeme.rocher@gmail.com>
Date: Tue, 9 May 2017 08:34:57 +0200
Message-ID: <CAO_wNofCkPZw0ds39oB1c8_58gWJq7Mt1946Of1sK4qPgkHUpw@mail.gmail.com>
Subject: Re: Groovy AOT compilation
To: users@groovy.apache.org
Cc: Paul King <paulk@asert.com.au>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
archived-at: Tue, 09 May 2017 06:35:24 -0000

Would it make sense to have the metaClass field of GroovyObject
initialise lazily? In what circumstance would that be a breaking
change? Concurrency?

On Tue, May 9, 2017 at 8:25 AM, C=C3=A9dric Champeau
<cedric.champeau@gmail.com> wrote:
> The reason is that even with static compilation, constructors include
> metaclass initialization. This is something that have been bothering me f=
or
> a long time, and I wish we could rework that, but it's a behavioral break=
ing
> change (however, really unlikely to break things in real world).
>
> 2017-05-09 8:16 GMT+02:00 Sergei Egorov <bsideup@gmail.com>:
>>
>> Dear Paolo,
>>
>> Could you please share an example project? I would like to play with it =
:)
>>
>>
>> Best Regards,
>> Sergei
>>
>> On Tue, May 9, 2017 at 1:04 AM Paolo Di Tommaso
>> <paolo.ditommaso@gmail.com> wrote:
>>>
>>> That would make sense. However apart of that there's still a lot of
>>> reflection behind the scene even when using StaticCompile. For example =
just
>>> replacing the println statement with a `new Hello()` in the previous
>>> snippet, I'm getting the following errors when trying to compile with t=
he
>>> AOT compiler:
>>>
>>>
>>>
>>> groovy.lang.MetaClassRegistry$MetaClassCreationHandle.createWithCustomL=
ookup(Class,
>>> MetaClassRegistry): Method is marked as deleted:
>>> HotSpotMethod<Class.getConstructor(Class[])>
>>> at
>>> groovy.lang.MetaClassRegistry$MetaClassCreationHandle.createWithCustomL=
ookup(MetaClassRegistry.java:149)
>>> at
>>> groovy.lang.MetaClassRegistry$MetaClassCreationHandle.create(MetaClassR=
egistry.java:144)
>>> at
>>> org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInf=
o.java:259)
>>> at
>>> org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:30=
2)
>>> at Hello.$getStaticMetaClass(Hello.groovy)
>>> at Hello.<init>(Hello.groovy)
>>> at Hello.main(Hello.groovy:5)
>>> at com.oracle.svm.core.JavaMainWrapper.run(stripped:111)
>>>
>>> org.codehaus.groovy.reflection.CachedClass$8.initValue(): Method is
>>> marked as deleted: HotSpotMethod<Class.getInterfaces()>
>>> at
>>> org.codehaus.groovy.reflection.CachedClass$8.initValue(CachedClass.java=
:216)
>>> at
>>> org.codehaus.groovy.reflection.CachedClass$8.initValue(CachedClass.java=
:214)
>>> at
>>> org.codehaus.groovy.util.LazyReference.getLocked(LazyReference.java:49)
>>> at org.codehaus.groovy.util.LazyReference.get(LazyReference.java:40)
>>> at
>>> org.codehaus.groovy.reflection.CachedClass.getMethods(CachedClass.java:=
274)
>>> at
>>> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.initialize(Closu=
reMetaClass.java:474)
>>> at
>>> org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInf=
o.java:260)
>>> at
>>> org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:30=
2)
>>> at Hello.$getStaticMetaClass(Hello.groovy)
>>> at Hello.<init>(Hello.groovy)
>>> at Hello.main(Hello.groovy:5)
>>> at com.oracle.svm.core.JavaMainWrapper.run(stripped:111)
>>>
>>>
>>> Here the offending methods are Class.getConstructor(Class[]) and
>>> Class.getInterfaces().
>>>
>>> Does the MetaClassRegistry mechanism is really needed when using the
>>> Groovy static compilation ?
>>>
>>>
>>> p
>>>
>>> On Tue, May 9, 2017 at 12:29 AM, Paul King <paulk@asert.com.au> wrote:
>>>>
>>>> That line was added to break a hard-dependency on the groovy-xml modul=
e
>>>> by the core groovy module. With Java 9's "real" modules, we'd potentia=
lly
>>>> want to rework that. I haven't really thought about what we might do i=
nstead
>>>> but welcome to suggestions/ideas/PRs.
>>>>
>>>> Cheers, Paul.
>>>>
>>>>
>>>> On Tue, May 9, 2017 at 6:35 AM, Paolo Di Tommaso
>>>> <paolo.ditommaso@gmail.com> wrote:
>>>>>
>>>>> Good question. I leave the answer to Groovy core developers, however =
as
>>>>> far as I've understood even when the code is statically compiled, Gro=
ovy
>>>>> still uses reflection in runtime helper methods. For example one of t=
he
>>>>> first issue I've encountered it's raised by the following line in the
>>>>> InvokeHelper.format method that the AOT compiler is unable to transla=
te to
>>>>> native code
>>>>>
>>>>>   Method serialize =3D
>>>>> Class.forName("groovy.xml.XmlUtil").getMethod("serialize", Element.cl=
ass);
>>>>>
>>>>>
>>>>>
>>>>> p
>>>>>
>>>>> On Mon, May 8, 2017 at 5:35 PM, Winnebeck, Jason
>>>>> <Jason.Winnebeck@windstream.com> wrote:
>>>>>>
>>>>>> I think a biggest question than AOT compatibility is why does compil=
e
>>>>>> static still need to do reflection? I thought that was the point was=
 to
>>>>>> disable it, especially for Android support=E2=80=A6? Unless the issu=
e is the
>>>>>> metaclass generation, does compile static still generate metaclasses=
?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Jason
>>>>>>
>>>>>>
>>>>>>
>>>>>> From: Paolo Di Tommaso [mailto:paolo.ditommaso@gmail.com]
>>>>>> Sent: Monday, May 08, 2017 11:02 AM
>>>>>> To: users@groovy.apache.org
>>>>>> Subject: Groovy AOT compilation
>>>>>>
>>>>>>
>>>>>>
>>>>>> Dear all,
>>>>>>
>>>>>>
>>>>>>
>>>>>> I just want to share with you my experience with the Java AOT compil=
er
>>>>>> a came across a few days ago.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Although they said clearly that it still an experimental project and
>>>>>> it does not support dynamic class loading and most of reflection, I =
turns
>>>>>> out it's possible to compile a basic static Groovy class, eg:
>>>>>>
>>>>>>
>>>>>>
>>>>>> @groovy.transform.CompileStatic
>>>>>>
>>>>>> class Hello {
>>>>>>
>>>>>>
>>>>>>
>>>>>>   static void main( String... args ) {
>>>>>>
>>>>>>     System.out.println "Hello world!"
>>>>>>
>>>>>>   }
>>>>>>
>>>>>> }
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> This mean that it creates a native 5MB binary executable, that can r=
un
>>>>>> on any machine without the need of the Java VM nor the Groovy runtim=
e! in 12
>>>>>> millisecond! cool!!
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Unfortunately the good news stops here. I was unable to successfully
>>>>>> compile any other piece of code, which for example uses a Groovy "pr=
intln"
>>>>>> method or just instantiate a class. The problem seems to be that, ev=
en
>>>>>> though the code is statically compiled, Groovy uses reflection behin=
d the
>>>>>> scene to instantiate classes and performs other operations.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Now, I guess this is certainly not a Groovy top priority, however
>>>>>> since there is an on-going discussion around a major Groovy reengine=
ering to
>>>>>> make it compatible with the upcoming Java 9 module system, I was won=
dering
>>>>>> if it would not make sense to include the support for the Java AOT c=
ompiler
>>>>>> as a goal for a future Groovy 3/4 release?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Personally I think it would be an extremely useful feature and a maj=
or
>>>>>> achievement for the project.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> What do you think ?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Paolo
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> This email message and any attachments are for the sole use of the
>>>>>> intended recipient(s). Any unauthorized review, use, disclosure or
>>>>>> distribution is prohibited. If you are not the intended recipient, p=
lease
>>>>>> contact the sender by reply email and destroy all copies of the orig=
inal
>>>>>> message and any attachments.
>>>>>
>>>>>
>>>>
>>>
>


--=20
Graeme Rocher