Graal native image support about spring-fu HOT 18 CLOSED

Spring Fu minimal webapp is now compiling to a native image successfully with Graal 1.0.0.RC2, Kotlin 1.2.60 (will also work with 1.2.51) and Netty!!!

Startup time is 33 ms with Graal (to be compared with 900 ms with Java 10). The self-sufficient executable size is 50 MB but we will maybe be able to reduce it via #34.

Jetty also works.

from spring-fu.

@sdeleuze RC6 should come out in 1 week or less.

from spring-fu.

@cstancu Awesome thanks

from spring-fu.

I reopen this issue since oracle/graal#655 regression makes it impossible to compile a Spring Fu webapp with Graal 1.0.0-RC6.

from spring-fu.

Kotlin ticket: https://youtrack.jetbrains.net/issue/KT-23962

from spring-fu.

With KT-23962 and graal#416 now fixed we should now give it another try.

from spring-fu.

I think we are quite close to get it working. On this branch with Graal 1.0.0.RC2, the executable is created and throw this exception when running:

Exception in thread "main" java.lang.reflect.InvocationTargetException
	at java.lang.Throwable.<init>(Throwable.java:310)
	at java.lang.Exception.<init>(Exception.java:102)
	at java.lang.ReflectiveOperationException.<init>(ReflectiveOperationException.java:89)
	at java.lang.reflect.InvocationTargetException.<init>(InvocationTargetException.java:72)
	at com.oracle.svm.reflect.proxies.Proxy_94_ApplicationKt_main.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.oracle.svm.core.JavaMainWrapper.run(JavaMainWrapper.java:173)
Caused by: com.oracle.svm.core.jdk.UnsupportedFeatureError: RuntimeMXBean methods
	at java.lang.Throwable.<init>(Throwable.java:265)
	at java.lang.Error.<init>(Error.java:70)
	at com.oracle.svm.core.jdk.UnsupportedFeatureError.<init>(UnsupportedFeatureError.java:31)
	at com.oracle.svm.core.jdk.Target_com_oracle_svm_core_util_VMError.unsupportedFeature(VMErrorSubstitutions.java:105)
	at com.oracle.svm.core.jdk.SubstrateRuntimeMXBean.getUptime(JavaManagementSubstitutions.java:238)
	at org.springframework.fu.ApplicationDsl.run(ApplicationDsl.kt:181)
	at org.springframework.fu.ApplicationDsl.run$default(ApplicationDsl.kt:164)
	at org.springframework.fu.sample.minimal.ApplicationKt.main(Application.kt:35)
	... 3 more

Not sure yet how we could avoid using RuntimeMXBean methods to avoid this error.
Any thoughts @dsyer @jhoeller?

from spring-fu.

Good news, KT-23962 will be fixed in upcoming Kotlin 1.2.51.

from spring-fu.

Thanks for finding a (previously) unused corner of the SubstrateVM runtime. I have filed an issue to implement RuntimeMXBean.getUptime(). Not all of the RuntimeMXBean methods make sense in the context of a native image. Are there others you need, and what do you think they should they should return?

from spring-fu.

@Peter-B-Kessler Thanks! In Spring Boot, we use getName() (to get the PID) and getClassPath() (which could maybe be replaced by System.getProperty("java.class.path")) in addition to getUptime(). Do you think those would make sense with SubstrateVM runtime?

from spring-fu.

RuntimeMXBean.getName() already returns the "expected" pid@hostname. (At some point we will support JDK-9 and the ProcessHandle.pid() method and I will sleep better.)

RuntimeMXBean.getClassPath() should return null because there is no path from which SubstrateVM loads classes at runtime. Similarly RuntimeMXBean.getBootClassPath() should return null.

When I implement RuntimeMXBean.getUptime() I will see what can be done for the rest of the RuntimeMXBean methods.

from spring-fu.

Ok thanks a lot!

from spring-fu.

@Peter-B-Kessler Any chance you could notice me when this is on GraalVM master in order to allow me to try it and make progress on the Boot side as well?

from spring-fu.

The changes are in https://github.com/oracle/graal/blob/master/substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/jdk/JavaManagementSubstitutions.java. I don't know what the release schedule is for the next set of built binaries. You could build from sources by following the instructions in https://github.com/oracle/graal/blob/master/substratevm/README.md.

You might be disappointed that getClassPath() returns null, but that is the correct value for it to return: there is no class path at runtime.

getUptime() (and getStartTime()) depend on a startup hook that runs if your application is called from the usual static void main(String[]) entry point. If you embed SubstrateVM in another application and start it from a different entry point, to get reasonable answers from those methods you will have to call those startup hooks yourself, via RuntimeSupport.executeStartupHooks().

from spring-fu.

Make sense thanks.

Next issue we face: oracle/graal#507

from spring-fu.

I have updated graal branch in order to leverage GraalVM 1.0 RC3. Sadly we have a regression under investigation, see https://twitter.com/sdeleuze/status/1014051429621862400. For now, I have updated the branch to leverage Jetty instead.

from spring-fu.

Related Spring Framework issue for GraalVM native image support is SPR-16991.

from spring-fu.

@Peter-B-Kessler @cstancu Any plan to release a RC6 shortly? It would allow our user to create Spring Fu apps that works out of the box as native images.

from spring-fu.