GraalVM native-image support

[viesti]

This would allow building to native executable. I'm thinking that we could add a namespace for calling the native-image tool, with suitable defaults (example from jet).

[SevereOverfl0w]

If I did this I'd want it to be really easy, no setting of GRAAL_HOME or whatever. It should just be automatic.

[SevereOverfl0w]

https://www.graalvm.org/sdk/javadoc/ is this what we are after? The native image parts? Not sure.

[viesti]

I didn't actually go as far as checking if there is a Java API available. If such exists, it would be a good match to help with being "automatic" :)

[SevereOverfl0w]

https://medium.com/graalvm/simplifying-native-image-generation-with-maven-plugin-and-embeddable-configuration-d5b283b92f57 suggests the maven plugin is doing it

[viesti]

Ahaa!, that set's a target for us then :)

[viesti]

I have to admit not doing proper background research as there are atleast two tools, https://github.com/luchiniatwork/cambada and https://github.com/taylorwood/clj.native-image, that operate in this area. If native-image has a library api (and is available as a dependency), it would set pack apart from the other tools.

[viesti]

This looks a bit bad 😬 https://github.com/oracle/graal/blob/master/substratevm/src/native-image-maven-plugin/src/main/java/com/oracle/substratevm/NativeImageMojo.java#L166:

Path nativeImageExecutable = getJavaHome().resolve("bin").resolve(withExeSuffix("native-image"));

The "Simplifying native-image generation with Maven plugin and embeddable configuration" post states:

If you are using GraalVM as your JAVA_HOME it is sufficient to just add:

<plugin>
   <groupId>com.oracle.substratevm</groupId>...

So I guess it relies on the native-image tool being available in the path.
Anyway, thanks for helping on looking into this :)

[SevereOverfl0w]

There's also this following that:

it is also possible to build images even without having a GraalVM release installed on your system. The only requirement is to have a JVMCI enabled JDK on your machine. 

[SevereOverfl0w]

Seems like JVMCI is a draft proposal, and only graal is building open jdk with it for now. (These are both statements that need confirming).

I would not be opposed to downloading graalvm into a cache directory and shelling out to that native-image if graalvm cannot be found via the normal methods.

[SevereOverfl0w]

jvmci doesn't exist in my oracle jdk install..

[viesti]

Seems that from 19.00 onwards (see github releases page), native-image was extracted from the Graal distribution and is available as a jar, but it is not independent and relies on the Graal distribution. 300MB of Graal seems like quite a drink in the cache, but might still be worth a try for better usability :) I wonder what is the minimum of deps that the utility actually needs from inside graal...

[SevereOverfl0w]

It's a big cache, but you will need it downloaded either way. Pack can do it for you, or you can do it and specify the location. The cache would be a fallback. Some kind of garbage collection seems worthwhile though.

The idea of tree shaking graal sounds interesting :p.

[viesti]

Thinking out loud:

Maybe we could check for latest release of Graal and even prompt to upgrade to it. A --cache-dir that has a default (say ~/graalvm-cache) would allow users to manage the location of the install. A Graal version could even be selectable via --version, which would default to latest version in the cache directory.

I don't know if native-imagehas different release schedule than graal itself. If so, this might be an additional update step. Initial (and updates) download of native-image could be done via gu utility, so we don't have to perform native-image installation.

[SevereOverfl0w]

My thinking was something along the lines of checking for GRAALVM_HOME, checking if JAVA_HOME contains native-image, then finally creating/updating the cache otherwise.

https://github.com/soc/directories-jvm I'd probably use this for the cache location, because I'm a sucker for compliance.

[viesti]

TIL directories-jvm :) This sounds like good reasoning to me.