groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From CĂ©dric Champeau <cedric.champ...@gmail.com>
Subject Re: Groovy AOT compilation
Date Tue, 09 May 2017 06:25:50 GMT
The reason is that even with static compilation, constructors include
metaclass initialization. This is something that have been bothering me for
a long time, and I wish we could rework that, but it's a behavioral
breaking 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 the
>> AOT compiler:
>>
>>
>> groovy.lang.MetaClassRegistry$MetaClassCreationHandle.createWithCustomLookup(Class,
>> MetaClassRegistry): Method is marked as deleted: HotSpotMethod<Class.
>> getConstructor(Class[])>
>> at groovy.lang.MetaClassRegistry$MetaClassCreationHandle.
>> createWithCustomLookup(MetaClassRegistry.java:149)
>> at groovy.lang.MetaClassRegistry$MetaClassCreationHandle.
>> create(MetaClassRegistry.java:144)
>> at org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(
>> ClassInfo.java:259)
>> at org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:
>> 302)
>> 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(ClosureMetaClass.java:474)
>> at org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(
>> ClassInfo.java:260)
>> at org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:
>> 302)
>> 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 module
>>> by the core groovy module. With Java 9's "real" modules, we'd potentially
>>> want to rework that. I haven't really thought about what we might do
>>> instead 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, Groovy
>>>> still uses reflection in runtime helper methods. For example one of the
>>>> first issue I've encountered it's raised by the following line in the
>>>> InvokeHelper.format
>>>> <https://github.com/apache/groovy/blob/GROOVY_2_4_11/src/main/org/codehaus/groovy/runtime/InvokerHelper.java#L607>
>>>> method that the AOT compiler is unable to translate to native code
>>>>
>>>>   Method serialize = Class.forName("groovy.xml.XmlUtil").getMethod("serialize",
>>>> Element.class);
>>>>
>>>>
>>>>
>>>> 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 compile
>>>>> static still need to do reflection? I thought that was the point was
to
>>>>> disable it, especially for Android support…? Unless the issue 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 compiler
>>>>> <http://www.oracle.com/technetwork/oracle-labs/program-languages/overview/index.html>
>>>>> 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 run
>>>>> on any machine without the need of the Java VM nor the Groovy runtime!
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 "println"
>>>>> method or just instantiate a class. The problem seems to be that, even
>>>>> though the code is statically compiled, Groovy uses reflection behind
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 reengineering
>>>>> to make it compatible with the upcoming Java 9 module system, I was
>>>>> wondering if it would not make sense to include the support for the Java
>>>>> AOT compiler as a goal for a future Groovy 3/4 release?
>>>>>
>>>>>
>>>>>
>>>>> Personally I think it would be an extremely useful feature and a major
>>>>> 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, please
>>>>> contact the sender by reply email and destroy all copies of the original
>>>>> message and any attachments.
>>>>>
>>>>
>>>>
>>>
>>

Mime
View raw message