groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paolo Di Tommaso <paolo.ditomm...@gmail.com>
Subject Re: Groovy AOT compilation
Date Mon, 08 May 2017 23:03:25 GMT
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